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

Jonathan Frederic jon.freder at gmail.com
Mon Jul 27 11:04:31 EDT 2015


(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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150727/828ad5b3/attachment.html>


More information about the IPython-dev mailing list