<p dir="ltr"><br>
On Jul 27, 2015 10:01 AM, "Jonathan Frederic" <<a href="mailto:jon.freder@gmail.com">jon.freder@gmail.com</a>> wrote:<br>
><br>
> Hmm makes me think we could, in the future,  have inputs+(outputs&runtime state).  Or inputs+outputs+runtime state, all zipped into a single file.  If users want they could choose only to store inputs, which would be a diff file extensions, and not use zipping.  (Like M$ office's save with macros or without, which now uses two separate file exts)<br>
><br>
> P.s. when I say runtime state, I'm thinking widgets.</p>
<p dir="ltr">For reproducibility,</p>
<p dir="ltr">* runtime state<br>
* versions<br>
* actual source code<br>
* installed binary packages (e.g. archived docker image)</p>
<p dir="ltr">... This looks really useful.</p>
<p dir="ltr">It would be great to be able to go from a notebook.py3.ipynb.clean file to an installed docker container (with minimal knowledge of packaging), runipy, and save the HTML e.g. as notebook.py3.ipynb.html.</p>
<p dir="ltr">><br>
> On Jul 14, 2015 10:01 AM, "Thomas Kluyver" <<a href="mailto:takowl@gmail.com">takowl@gmail.com</a>> wrote:<br>
>><br>
>> On the flight back from Austin yesterday, I got some time to work on an idea I've had for a while: a contents manager that splits inputs/outputs and recombines them on load.<br>
>><br>
>> In some contexts, you want to version control the code + markdown of a notebook and not the outputs, which may change more frequently, and may include big blobs of binary data which VCSs don't handle well. There are tools available to strip outputs out before committing, but then you lose the outputs locally as well. And if any collaborator doesn't set up that tool, they might accidentally commit the outputs.<br>
>><br>
>> With this contents manager, when you save a notebook, you get an extra Whatever.ipynb.clean file, with no outputs or execution_count prompt numbers. Whatever.ipynb is also saved as normal, with the outputs left intact.<br>
>><br>
>> The idea is that you would commit the .ipynb.clean files, and tell the VCS to ignore .ipynb files, keeping them as a local cache of the outputs from running the notebook.<br>
>><br>
>> If someone else changes the 'clean' copy in version control, it may no longer match your local cache. When you open the notebook, the clean copy is considered authoritative, but it still tries to use information from the cached 'dirty' copy. It uses difflib to match up code cells that haven't changed, and reinstates the output from the cache.<br>
>><br>
>> The code, and an example notebook with only the clean part in version control, are here:<br>
>> <a href="https://github.com/takluyver/recombinecm">https://github.com/takluyver/recombinecm</a><br>
>><br>
>> N.B. Both files will show up the file list, but you need to click the .ipynb to open the notebook. I'm still thinking about how to make this neater.<br>
>><br>
>> Thomas<br>
>><br>
>> _______________________________________________<br>
>> IPython-dev mailing list<br>
>> <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
>> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> IPython-dev mailing list<br>
> <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
><br>
</p>