Shall I push the sort_keys to master? It's a one-line change in nbformat/v2/nbjson.py:<div><br></div><div><div>diff --git a/IPython/nbformat/v2/nbjson.py b/IPython/nbformat/v2/nbjson.py</div><div>index b86297d..e67bec3 100644</div>
<div>--- a/IPython/nbformat/v2/nbjson.py</div><div>+++ b/IPython/nbformat/v2/nbjson.py</div><div>@@ -48,6 +48,7 @@ class JSONWriter(NotebookWriter):</div><div> def writes(self, nb, **kwargs):</div><div> kwargs['cls'] = BytesEncoder</div>
<div> kwargs['indent'] = 4</div><div>+ kwargs['sort_keys'] = True</div><div> return json.dumps(nb, **kwargs)</div><div><br></div><div><br></div><div>Since loading from JSON is not sensitive to ordering, this can't have any effect on the content of existing notebooks, other than a reorder of keys in the file the first time it is saved.</div>
<div><br></div><div>-MinRK</div><br><div class="gmail_quote">On Sat, Nov 5, 2011 at 20:08, MinRK <span dir="ltr"><<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div><div class="h5">On Sat, Nov 5, 2011 at 19:58, Fernando Perez <span dir="ltr"><<a href="mailto:fperez.net@gmail.com" target="_blank">fperez.net@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Sat, Nov 5, 2011 at 7:41 PM, MinRK <<a href="mailto:benjaminrk@gmail.com" target="_blank">benjaminrk@gmail.com</a>> wrote:<br>
> On Sat, Nov 5, 2011 at 18:58, Fernando Perez <<a href="mailto:fperez.net@gmail.com" target="_blank">fperez.net@gmail.com</a>> wrote:<br>
>><br>
<br>
</div><div>> There is a *huge* disadvantage in portability to notebooks not being single<br>
> files. I think this still makes<br>
> sense, though. I would treat the output as a 'cache' (along the lines of<br>
> .pyc / __cache__),<br>
> rather than considering the notebook itself as a multi-file format. And you<br>
> should be able<br>
> to embed the outputs in a single file if you want, for easier portability.<br>
> Doing it this way would not require changing the notebook format, because<br>
> current (output-included)<br>
> notebooks would still comply with the spec.<br>
<br>
</div>I agree that it's a big inconvenience for everyday, non-VC use. I<br>
like the idea of making it optional, it can be a flag set in the<br>
metadata dict, that indicates whether to keep outputs in the cache or<br>
internally (and also to offer the single-file download option).<br>
<div><br>
<br>
> I think this sounds like a good start, with the only change that we still<br>
> allow (optionally) outputs in a single file via the download button, rather<br>
> than the notebook format being canonically multifile, which is just too<br>
> painful.<br>
<br>
</div>Yes, that sounds like a good balance between everyday usability and<br>
being VC-friendly.<br>
<div><br>
> I think the key-order issue you mention in the addendum is easily fixed by<br>
> specifying `sort_keys=True` in the json dump.<br>
<br>
</div>That's great to hear, I thought we'd have to do the sorting manually.<br>
That's a change we should make right away then, since it doesn't<br>
change the format. People can manually remove outputs from their<br>
notebooks and this will help if they use VC a little bit (even if the<br>
singe-line cells issue isn't fixed yet).<br></blockquote><div><br></div></div></div><div>Yes, and if I recall, for now you can just hit 'ClearAll outputs' prior to save/commit, to remove output from VCS.</div>
<div class="im"><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks for the feedback!<br>
<br>
Cheers,<br>
<span><font color="#888888"><br>
f<br>
</font></span></blockquote></div></div><br>
</blockquote></div><br></div>