-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Outsource the "pure python notebook" lib #933
Comments
Instead of requiring a separate lib, could |
Not really, as EDIT: actually #421 was more about rich output (scrapers), my proposal is really much more focused on simple cell-by-cell execution and results collection. So, the two tickets are not that connected |
Makes sense then!
In some sense "rich scraping" could be considered a form of "results collection" / "output" capture. It really depends on what me mean by "output". If by "output" you mean stdout/stderr and not anything graphical, then scrapers would be excluded, and would stay in the sphinx-gallery scope. But would this really be optimal for mkdocs-gallery? I would assume that getting execution + prints + figures/images would be much more useful, no? |
Yes, you are right. I guess that we could start with pure doc extraction + block-wise execution + config + raw output variables gathering, and then add an optional scrapers engine. |
Hi @larsoner , long time no chat :) I was trapped in many other industrial activities unfortunately. Do you have an opinion about how this could possibly be a candidate to replace the "common core" that I was mentioning above ? Or is this lib "not independent enough" (from jupyter) in your mind to be a suitable core engine for sphinx-gallery ? |
At least 4 years ago they used our code for conversion I think? But maybe it's not that way today... |
jupytext depends on nbformat which then draws a lot of dependencies.
We would like sphinx-gallery to remain lightweight to setup. In my view one of the current limitations of sphinx-gallery is that it is too tedious to setup (eg on a CI). Of course, this is not related to the dependencies, and there would be not absolute opposition to adding a small dependency if it simplifies things a lot.
Beside, the hardest part of converting to notebook format is the move from rst to md, which would be needed anyhow to benefit from jupytext.
I think that, if we were to make major movements, one promising direction (but a major movement) would be to look at the growing md support of sphinx. But I'm not sure how we would make this work with the part that interacts with formatting the docstrings of the project that we are documenting.
|
Very clear @GaelVaroquaux thanks ! So better an independent lib in charge of managing this rst (and possibly md in the future) representation and execution of a notebook, than trying to reuse jupytext because of its dependency to nbformat. |
Today while working on #930, thinking that I was going to duplicate the fix for mkdocs-gallery (#895),
I asked myself what could be the scope of a common core lib supporting both.
At least there is one thing that would make sense: the "pure python notebook engine", that currently
We could call such a shared lib "pynotebook" but the name is already used, so maybe something like "pure_notebook" ?
What do you think ?
The text was updated successfully, but these errors were encountered: