Split projects!
jstac opened this issue · 9 comments
OK, so this is a big one.
The plan is to divide this project into three parts:
- Python for Quantitative Economics (python-programming.quantecon.org)
- Introduction to Quantitative Economics with Python (python-intro.quantecon.org)
- Advanced Quantitative Economics with Python (python-advanced.quantecon.org)
What's up for discussion is (a) the exact split and (b) how to do it.
Regarding (a), @thomassargent30 and I will go through and flag lectures appropriately.
Regarding (b), we need to think about cross-references and new directory structure.
One possibility is to keep this repo and include in it three jupinx projects. The other is to create three repos, one for each project. The first option is probably easier but the second would be more conventional.
@mmcky and @AakashGfude , it would be good to hear your thoughts.
@jstac I agree from a technical perspective I think the main piece to understand is:
- develop an approach / convention for linking between sphinx repositories. There are a number of possibilities here such as a sphinx extension to support interdocument links, or web links.
I guess I would lean towards having separate repository where each uses a common name conventions such as lectures.python-{project}
. The main reason is that if we had a single repo with three folders (each a separate sphinx project) -- PR's / Issue tracking may be more difficult as we work out which project they pertain to etc. In addition a pull of one project shouldn't really necessitate the fetching of sources for the others.
Regarding repos, you are right. Let's split them up. (It's a bit painful to shift over existing issues but better to go through that pain first up and then have smoother sailing.)
I think they can all be styled in the same way.
@jstac , I suppose the three splits will be mutually exclusive in terms of lectures then? And will we scrap the graduate and undergraduate course tabs?
That's correct @AakashGfude .
As for linking, mentioned by @mmcky, I wonder if there's a good way to do it. It would be great if you could look into it. But the worst case scenario is not too bad: For cross-refs that would point out to one of the other projects, we replace a precise reference to a lecture to a general reference to the project.
("more info can be found in :doc:this lecture <xxx>
" becomes "more info can be found in the section on topic yyy in project zzz <external_link>
_)
Thanks, @jstac , @mmcky and @AakashGfude . I agreed with your ideas about splitting repos.
Hi @jstac , regarding linking, we should probably consider three things:
- Whether those links work for an individual/all pdf.
- Whether those links work for an individual jupyter notebook (JN).
- Whether those links work for the above files in Points 1 and 2 (downloadable JN) without the internet.
A similar problem @AakashGfude and I face when we are going to fix issue #926 . In issue #926, if we replace the reference with external links to the website, then it would make the life of offline readers a bit harder.
The effect of these problems can be minimized if we assume that most readers have internet.
@jstac an update on progress.
We now have the repositories setup for:
along with associated:
.theme
for private quantecon, and.notebooks
repositories to support google colab
They build each project and I am manually populating the preview
buckets for testing and review of html
The following still needs to be done:
- complete and test QuantEcon.aws.admin PR to trigger automated builds for the new lecture series (@mmcky)
- create landing pages for
python.quantecon.org
(@DrDrij) - work through
sphinx
warnings inlecture-python-intro
andlecture-python-advanced
(will raise issues on each repo to track progress). These largely consist of no longer valid links and labels. (@mmcky + RA support) - verify lectures are in the correct repositories and
index
files are all up to date (@jstac + RA support) - adjust all themes to remove
undergraduate
andgraduate
tab index support (@DrDrij)
Regarding timeline I don't think we will be able to switch
by tomorrow but all the infrastructure
should be in place to deploy
the new structure when we are happy with the new projectcontent and all sphinx
warnings are resolved.
My aim is:
- finalise all required
infrastructure
to meet Friday 13th March target - Implement freeze on
lecture-source-py
and transfer finalrst
files to new repository locations + freeze updates to thelive
site (Friday 13th March) - with RA support work to resolve
sphinx
warnings with missing labels and add PR's to smooth the language around cross-project links (I suspect this will be ~1 week) acrosslecture-python-intro
andlecture-python-advanced
(mainly) - switch from
python.quantecon.org
-> 3 x project structure forlive
sites.
closing this issue as the remainder is documented in #957