Notebooks (and this command-line ebook) assume that the input data is static (i.e. an ad-hoc analysis) which is a more typical use case.

Dynamic data/reporting is a different thing entirely, at which point things like business intelligence software and dashboards come into play, and outside the scope of a command line anyways.

I might have needed to edit down my comment, but you locked on to the least important part of my argument.

If reproducibility is important, like you say, then a notebook is the last thing you want. Your code needs to be tested and designed like the software it is, instead of tossed into some notebook that does not fit into classic software practices.

Notebooks however let you run code blocks in arbitrary orders, delete ones but keep their results in memory, change them without rerunning and change code with none of the downstream dependencies updating.

It's possible (actually very easy) to have code which works as you're making it but not if you run it from scratch.

Which is why notebooks typically a) declare all imports/dependencies in the first block and b) the entire notebook is rerun from a fresh session before publishing (and notebooks have a keyboard command for doing that too).

In all my years of work with Notebooks, I've never had an issue with downstream dependencies.

Important distinction: the notebooks themselves don't do this. The notebook authors, by convention, are supposed to do this.

This is no different than engineers who are, by convention, supposed to write bug-free code. Even with this convention, however, devs still rely on testing to decrease the likelihood of bugs.

No similar tooling exists for notebooks, which is why I recommend moving re-used logic into a tested codebase.