<div><span style="color: rgb(160, 160, 168); ">On Thursday, February 28, 2013 at 10:39 AM, Mark McLoughlin wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>Hey,</div><div><br></div><div>(I sent this to the wrong list and was directed here by Nick. I wasn't</div><div>aware of the very promising sounding PEP426 and haven't read it yet, so</div><div>apologies on that. Just wanted to resend my mail here ASAP to prevent</div><div>the discussion happening on the wrong list. Thanks!)</div><div><br></div><div>Generally speaking, when a project has a large list of dependencies on</div><div>libraries outside of its control, it can take one of two approaches to</div><div>those dependencies:</div><div><br></div><div> 1) specify the minimum required version of each library and assume new</div><div> releases of all your dependencies will be backwards compatible with </div><div> previous versions. You feel safe that if an incompatible version of </div><div> the library is released, it will be a completely new stream and you </div><div> can adopt the new stream at your leisure.</div><div><br></div><div> I'm much more familiar with C libraries than any other language. </div><div> Somehow, C library maintainers seem to understand the need for this </div><div> approach and so you've got mechanisms like libtool managed sonames</div><div> and parallel installable libraries like gtk, gtk2, gtk3.</div><div><br></div><div> 2) specify exactly what version of each library to use, because you </div><div> assume all of your dependencies are constantly changing their APIs </div><div> and breaking your app</div><div><br></div><div> This is what you see in the Ruby (bundler) and Java (maven) worlds. </div><div> For distribution packagers, it presents horrific problems - either</div><div> you accept that you're going to be packaging (potentially many)</div><div> different versions of the same library and that any time a security </div><div> issue comes up you need to patch each version.</div><div><br></div><div>Personally, I tend to pour scorn on Ruby and Java folks for the chaotic</div><div>nature that pushes app developers down this "I need to control the whole</div><div>stack of dependencies because they're so unstable" path.</div><div><br></div><div>OTOH, I hear the Perl community are pretty good about taking the first</div><div>approach.</div><div><br></div><div>I always felt that the Python community tended more towards the former</div><div>approach, but there always exceptions to the rule - to unfairly pick one</div><div>one project, sqlalchemy seems to have an API that often changes</div><div>incompatibly.</div></div></div></span></blockquote><div>SQLAlchemy is a 0.x so it's API is explicitly not stable yet. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>However, OpenStack is starting to get burned more often and some are</div><div>advocating taking the second approach to managing our dependencies:</div><div><br></div><div> <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-February/thread.html#6014">http://lists.openstack.org/pipermail/openstack-dev/2013-February/thread.html#6014</a></div><div> <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-February/thread.html#6041">http://lists.openstack.org/pipermail/openstack-dev/2013-February/thread.html#6041</a></div><div> <a href="http://lists.openstack.org/pipermail/openstack-dev/2012-November/002075.html">http://lists.openstack.org/pipermail/openstack-dev/2012-November/002075.html</a></div><div><br></div><div>It's probably not worthwhile for everyone to try and read the nuances of</div><div>those threads. The tl;dr is we're hurting and hurting bad. Is this a</div><div>problem the OpenStack and Python communities want to solve together? Or</div><div>does the Python community fundamentally seem themselves as taking the</div><div>same approach as the Ruby and Java communities?</div><div><br></div><div>Maybe it sounds like I'm trolling, but this is an honest question. What</div><div>I'd really like to hear back is "please, please OpenStack keep using the</div><div>first approach and we can work through the issues you're seeing and</div><div>together make Python better". We can totally do that IMHO.</div></div></div></span></blockquote><div>I don't think OpenStack should be pinning to exact versions in it's releases. I</div><div>do think that individual installs should be pinning to exact versions. I don't think</div><div>that you're likely to ever get a complete consensus on foo2, foo3 vs foo 2.0, foo 3.0</div><div>(personally I prefer foo 2.0, foo 3.0). However my suggestion would be to express</div><div>"expected" version ranges.</div><div><br></div><div>For example SQLAlchemy (to continue on your example) tends to bump it's second</div><div>digit (probably while it's still in 0.x) anytime a backwards incompat change is made. So</div><div>Instead of depending on `SQLalchemy`, or `SQLAlchemy==0.8.0` you could do something</div><div>like `SQLAlchemy>=0.8.0,<0.9`. This should function similarly to the "gtk, gtk2, gtk3" that</div><div>you're used to. Different projects will use different places for it's significant bit though.</div><div><br></div><div>In the future there will likely be a shortcut to handle this in the ~> operator (~>0.8.1 would</div><div>be equivalent to >=0.8.1<0.9).</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>If people want an example of the kind of stuff things we need to work</div><div>on:</div><div><br></div><div> <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-February/006048.html">http://lists.openstack.org/pipermail/openstack-dev/2013-February/006048.html</a></div><div><br></div><div>Thanks,</div><div>Mark.</div><div><br></div><div>_______________________________________________</div><div>Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a></div><div><a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>