4 ms·
The hard part is that introducing a tool like git (which requires you to choose moments to take a snapshot of the file, and then add some commit message) breaks
by ssivark 8y ago
The hard part is that introducing a tool like git (which requires you to choose moments to take a snapshot of the file, and then add some commit message) breaks the flow of interactive experimentation that notebooks are so good for. And then we need to find a way to make those commits useful, because the time ordering of commits could be different from the time order in which cells were run! That is what is crucial to making computations reproducible — viewers should be able to replay the history of how a notebook result came to be. (EDIT: Note that this is the case only for stateful computations -- if a notebook interface was used to construct a dataflow graph (like spreadsheets) with values updating live, then this wouldn't be so much of a problem. More fundamentally, it is not at all obvious that thinking of notebook contents as akin to code is the best way to use version control)
I wonder whether there is a solution along the lines of auto-committing each cell before it’s executed and the results just after the cell is executed. Otherwise a user has to do too much manual organizing, which is a problem the notebook should ideally solve. When a user is happy with the experiments and the provenance of their results, they should be able to use an interactive rebase to create a cleaner version to share/archive.
- ISL 8y agoI'm not a Jupyter user, but I solve the reproducibility problem with Make. As a project moves from exploration toward production, the entire thing is wrapped into a Makefile that can flow from raw data to publication in a single call to make.
- ontouchstart 8y agoTo have reproducible prototypes, I use Make to wrap the whole workflow in docker. Then I push the code to gist and forget about it. Although GitHub gist doesn't allow binary file, images embedded in .ipynb (JSON), on the other hand works in gist. Here is an example. https://gist.github.com/ontouchstart/854a3c280b81f530d3ae9cb4c1bcbdc4 https://gist.github.com/ontouchstart/854a3c280b81f530d3ae9cb... The notebook generated by nbconvert (see the instruction in the Makefile) is too big to display in GitHub gist Web UI but works fine in nbviewer. https://nbviewer.jupyter.org/gist/ontouchstart/854a3c280b81f530d3ae9cb4c1bcbdc4/raf.nbconvert.ipynb https://nbviewer.jupyter.org/gist/ontouchstart/854a3c280b81f...
- kristjansson 8y agoThis has been my solution as well. There’s little that feels as good as running `make -B report` and watching the whole thing be rebuilt from scratch. How do you manage encapsulating each step, and passing data between them?
- canhascodez 8y agoWould that be easier with rake than with make?
- ISL 8y agoI don't do it well. See https://github.com/4kbt/ReplicableAnalysis https://github.com/4kbt/ReplicableAnalysis and https://github.com/4kbt/PlateWash https://github.com/4kbt/PlateWash as examples. The former is smaller/less complicated. The latter was my thesis work -- more complicated and (unfortunately) abuses recursive calls to Make.
- rgardaphe 8y agoThis is a super valuable perspective! We (https://qri.io https://qri.io) are building a kind of git/github for datasets and are hoping to talk to would-be users about just this issue. Would love to have your feedback on it (particularly on how commits are registered). Mind if I ping you at the email address you listed? - Rico