[IPython-dev] Prototyping on a plane: Splitting-recombining contents manager

[Wes Turner]

On Jul 27, 2015 2:48 PM, "Wes Turner" <wes.turner at gmail.com> wrote:
>
>
> On Jul 27, 2015 10:01 AM, "Jonathan Frederic" <jon.freder at gmail.com>
wrote:
> >
> > 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)
> >
> > P.s. when I say runtime state, I'm thinking widgets.
>
> For reproducibility,
>
> * runtime state
> * versions
> * actual source code
> * installed binary packages (e.g. archived docker image)

* data URIs
* actual data

>
> ... This looks really useful.
>
> 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.
>
> >
> > On Jul 14, 2015 10:01 AM, "Thomas Kluyver" <takowl at gmail.com> wrote:
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> The code, and an example notebook with only the clean part in version
control, are here:
> >> https://github.com/takluyver/recombinecm
> >>
> >> 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.
> >>
> >> Thomas
> >>
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150727/f132fd21/attachment.html>