Hamel here, one of the core developers on this project. I just want to say that we are really excited about this new release of nbdev and the added functionality it brings to users. The thing I'm most excited about is that you can use nbdev for more things than ever before, such as: Documenting existing codebases (even if they aren't written in nbdev), blog posts, books, presentations, etc.
We also have an amazing notebook runner, as well as many other quality of life improvements. We will be adding more tutorials, walkthroughs and examples in the coming days. If you are interested in using nbdev please get in touch!
Other resources:
- A detailed walkthrough: https://www.youtube.com/watch?v=l7zS8Ld4_iA&t=3225s
- Blog post: https://www.fast.ai/2022/07/28/nbdev-v2/
- Documentation: https://nbdev.fast.ai/getting_started.html
- Conversation b/w Jeremy Howard and JJ Allaire: https://youtu.be/xxVVSxcjNQs
I don't dislike notebooks, but I definitely have one foot in the "don't use notebooks for serious software" camp. I recently worked on a project where we're trying a notebook as the development platform for a data visualization report. The designer uses the notebook + bokeh to iterate on the report, and then we use nbconvert with some environment variables to create reports for different datasets.
My biggest issue with this paradigm is we actually had a lot of problem getting notebook development to work consistently bug-free on the various environments we have (Windows, Linux, VScode vs in-browser Jupyter, etc). It seemed like it would've been so much easier to just use a vanilla python script that generates the html report files. With hot reloading the iteration could be just as fast.
The other issue is that everything was horribly slow with the amount of data we were dealing with (~150MB of json). This is probably more related to python/bokeh than the notebooks themselves, but it meant that re-executing some cells was painful and would often hang or block the IDE.
A from-scratch rewrite of nbdev was released today -- details on what's new are in the launch post:
https://www.fast.ai/2022/07/28/nbdev-v2/
Let me know if you have any questions or comments -- I'm the lead dev on the project. (If you're in the "I don't like notebooks" camp, please watch this first: https://www.youtube.com/watch?v=9Q6sLbz37gk )
This looks great! I'm curious though if there are ways to get a bit more control over page layout. For example, can you put three charts on one page and have them resize appropriately? Or put two charts next to each other (without relying on the charting library itself)? This functionality is pretty important for our use case, but I've been assuming that notebook-style formats, when they output to pdfs or a printed page, are just going to output html that gets split up by the rendering engine.
I love working with notebooks but hate the .ipynb file format with the burning passion of a thousand suns.
For those of you who are similarly affected, you may want to try jupytext. It is a tiny package that converts threeway between ipynb, plain python files (whose comment blocks are interpreted as markdown cells) and plain markdown files (whose code blocks are interpreted as code cells). Moreover, if you have jupytext installed, then jupyter will read and write python and markdown files transparently as notebooks so that you don't need to deal with the stupid ipynb files anymore. This is nice because then you can track the evolution of notebooks easily in git, and your local graybeards can edit notebooks with a plain text editor, with no need of a web browser at all.
Of course, the output cells are not saved, but this was always in bad taste anyway. If you want a nice html with the cell outputs you can run "jupyter nbconvert --execute --to html" from the command line (and yes, it will work with plain python or markdown files if you have jupytext installed).
Why this is not part of jupyter proper is beyond me.
EDIT: regarding nbdev, I would like to learn what are the advantages with respect to the minuscule jupytext thing. I'm particularly concerned by the soundness of the quarto dependency, which is a scary behemoth made by accretion of haskell and javascript.