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

[Nicholas Bollweg]

As I work more with contentsmanagers (ipymd) I wonder if there won't be a
place for a contentsmiddleware concept that could slap transforms like this
on top of other managers.

On ipymd, to store image outputs, we have several bad options: inline
![](data:) tags, which would be awful to diff, reference-style
![][#impyd-img-1234567] which would at least make the diff a little better.

Having a consistent way to dump these to.

How does all of this work without cell ids?

On Mon, Jul 27, 2015 at 11:04 AM Jonathan Frederic <jon.freder at gmail.com>
wrote:

> (Sorry I'm responding by phone,  I just saw the typos on my previous
> e-mail.   Curse my clumsy fingers!)  I meant: which would be a different
> file extension.
> On Jul 27, 2015 8: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.
>> 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/01f39130/attachment.html>