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

[Damián Avila]

> Nope - everything you need to recreate the Markdown cells is stored in
the 'clean' document, so there's no need to match them up. It's actually
redundant to even store them in the local cache file, but that was the
easiest way to do it.

Yep, you are right, re-reading the original paragraph is now clear to me,
thanks!

On Mon, Jul 27, 2015 at 5:04 PM Wes Turner <wes.turner at gmail.com> wrote:

>
> 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
> > >
>  _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-- 
Damián Avila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150728/437828e1/attachment.html>