Shall I push the sort_keys to master? It&#39;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[&#39;cls&#39;] = BytesEncoder</div>

<div>         kwargs[&#39;indent&#39;] = 4</div><div>+        kwargs[&#39;sort_keys&#39;] = 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&#39;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">&lt;<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>&gt;</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">&lt;<a href="mailto:fperez.net@gmail.com" target="_blank">fperez.net@gmail.com</a>&gt;</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 &lt;<a href="mailto:benjaminrk@gmail.com" target="_blank">benjaminrk@gmail.com</a>&gt; wrote:<br>
&gt; On Sat, Nov 5, 2011 at 18:58, Fernando Perez &lt;<a href="mailto:fperez.net@gmail.com" target="_blank">fperez.net@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
<br>
</div><div>&gt; There is a *huge* disadvantage in portability to notebooks not being single<br>
&gt; files.  I think this still makes<br>
&gt; sense, though.  I would treat the output as a &#39;cache&#39; (along the lines of<br>
&gt; .pyc / __cache__),<br>
&gt; rather than considering the notebook itself as a multi-file format.  And you<br>
&gt; should be able<br>
&gt; to embed the outputs in a single file if you want, for easier portability.<br>
&gt; Doing it this way would not require changing the notebook format, because<br>
&gt; current (output-included)<br>
&gt; notebooks would still comply with the spec.<br>
<br>
</div>I agree that it&#39;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>
&gt; I think this sounds like a good start, with the only change that we still<br>
&gt; allow (optionally) outputs in a single file via the download button, rather<br>
&gt; than the notebook format being canonically multifile, which is just too<br>
&gt; painful.<br>
<br>
</div>Yes, that sounds like a good balance between everyday usability and<br>
being VC-friendly.<br>
<div><br>
&gt; I think the key-order issue you mention in the addendum is easily fixed by<br>
&gt; specifying `sort_keys=True` in the json dump.<br>
<br>
</div>That&#39;s great to hear, I thought we&#39;d have to do the sorting manually.<br>
That&#39;s a change we should make right away then, since it doesn&#39;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&#39;t fixed yet).<br></blockquote><div><br></div></div></div><div>Yes, and if I recall, for now you can just hit &#39;ClearAll outputs&#39; 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>