<div dir="ltr">On Tue, Sep 2, 2008 at 9:53 AM, Stefan Van der Walt <span dir="ltr">&lt;<a href="mailto:stefan@sun.ac.za">stefan@sun.ac.za</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
</div>It&#39;s so annoying when projects ship files in &quot;contrib&quot; that are<br>
incompatible with the latest release -- kind of makes you wonder<br>
whether these people are serious about delivering good quality<br>
software. &nbsp;By investing a tiny amount of time in unit testing and peer<br>
reviewing code, the problem can mostly be eradicated. &nbsp;Seems worth it<br>
to me, a thousand times over.</blockquote></div><br>Actually, the mechanics here is that &#39;contrib&#39; stuff should just use the public api&#39;s of ipython. Sometimes, some extension may go through _ip.IP (which slates them for breakage), but it makes sense to provide a low-overhead way to contribute additional features.<br>
<br>One alternative would be to move all these extensions to separate package - kind of like package archive of emacs. Post-0.9, I think we should seriously consider adding a magic function that downloads and installs the latest version of ipython extensions package - this would also decouple the extension release cycle from ipython release cycle. Of course the problem is mostly psychological - code in &#39;contrib&#39; will mostly be invisible to everybody that doesn&#39;t go out to 1) find it and 2) enable it.<br>
<br>-- <br>Ville M. Vainio - <a href="http://vivainio.googlepages.com">vivainio.googlepages.com</a><br>blog=<a href="http://360.yahoo.com/villevainio">360.yahoo.com/villevainio</a> - g[mail | talk]=&#39;vivainio&#39;<br>
</div>