<div><span style="color: rgb(160, 160, 168); ">On Monday, March 4, 2013 at 5:29 PM, 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>On Mon, 2013-03-04 at 12:44 -0500, Donald Stufft wrote:</div><blockquote type="cite"><div>On Monday, March 4, 2013 at 12:36 PM, Mark McLoughlin wrote:</div></blockquote><div><br></div><blockquote type="cite"><div><blockquote type="cite"><div><div>If parallel incompatible installs is a hopeless problem in Python,</div><div>why</div><div>the push to semantic versioning then rather than saying that</div><div>incompatible API changes should mean a name change?</div></div></blockquote><div>Forcing a name change feels ugly as all hell. I don't really see what</div><div>parallel installs has much to do with anything. I don't bundle anything</div><div>and i'm ideologically opposed to it generally but I don't typically have</div><div>a need for parallel installs because I use virtual environments. Why</div><div>don't you utilize those? (Not being snarky, actually curious).</div></div></blockquote><div><br></div><div>It's a fair question.</div><div><br></div><div>To answer it with a question, how do you imagine Linux distributions</div><div>using virtual environments such that:</div><div><br></div><div> $> yum install -y openstack-nova</div><div><br></div><div>uses a virtual environment? How does it differ from bundling? (Not being</div><div>snarky, actually curious :)</div></div></div></span></blockquote><div>Ah, See I don't install Python software via package managers so for</div><div>that use case yes it'd probably be a lot like bundling.</div><div><br></div><div>So the biggest problem with the setuptools style multi versioning that</div><div>I can remember is that it modified the global system state via pth files. </div><div><br></div><div>I've got an idea for a system that would work for this use case however</div><div>it would result in app start up taking longer (meaninfully longer? I don't</div><div>know for sure). Although it would require either support from the linux</div><div>packagers or installation via a third party tool.</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>The approach that some Fedora folks are trying out is called "Software</div><div>Collections". It's not Python specific, but it's basically the same as a</div><div>virtual environment.</div><div><br></div><div>For OpenStack, I think we'd probably have all the Python libraries we</div><div>require installed under e.g. /opt/rh/openstack-$version so that you</div><div>could have programs from two different releases of OpenStack installed</div><div>on the same system.</div><div><br></div><div>Long time packagers are usually horrified at this idea e.g.</div><div><br></div><div> <a href="http://lists.fedoraproject.org/pipermail/devel/2012-December/thread.html#174872">http://lists.fedoraproject.org/pipermail/devel/2012-December/thread.html#174872</a></div><div><br></div><div>Some of the things to think about:</div><div><br></div><div> - Each of the Python libraries under /opt/rh/openstack-$version would </div><div> come from new packages like openstack-$version-python-eventlet.rpm -</div><div> how many applications in Fedora would have a big stack of "bundled" </div><div> python packages like OpenStack? 5, 10, 50, 100? Let's say it's 10 </div><div> and each one stack has 20 packages. That's 200 new packages which </div><div> need to be maintained by Fedora versus the current situation where </div><div> we (painfully) make a single stack of libraries work for all </div><div> applications.</div><div><br></div><div> - How many of these 200 new packages are essentially duplicates? Once </div><div> you go down the route of having applications bundle libraries like </div><div> this, there's going to basically be no sharing.</div><div><br></div><div> - What's the chance that that all of these 200 packages will be kept </div><div> up to date? If an application works with a given version of a </div><div> library and it can stick with that version, it will. As a Python </div><div> library maintainer, wow do you like the idea of 10 different</div><div> versions of you library included in Fedora?</div><div><br></div><div> - The next time a security issue is found in a common Python library,</div><div> does Fedora now have to rush out 10 parallel fixes for it?</div><div><br></div><div>You can see that reaction in mails like this:</div><div><br></div><div> <a href="http://lists.fedoraproject.org/pipermail/devel/2012-December/174944.html">http://lists.fedoraproject.org/pipermail/devel/2012-December/174944.html</a></div><div><br></div><div>and the "why can't these losers just maintain compatibility" view:</div><div><br></div><div> <a href="http://lists.fedoraproject.org/pipermail/devel/2012-December/175028.html">http://lists.fedoraproject.org/pipermail/devel/2012-December/175028.html</a></div><div> <a href="http://lists.fedoraproject.org/pipermail/devel/2012-December/174929.html">http://lists.fedoraproject.org/pipermail/devel/2012-December/174929.html</a></div><div><br></div><div>Notice folks complaining about Ruby and Java here, not Python. I can see</div><div>Python embracing semantic versioning and "just use venv" shortly leading</div><div>to Python being included in the list of "heretics".</div><div><br></div><div>Thanks,</div><div>Mark.</div><div><br></div><div>[1] - <a href="http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html-single/Software_Collections_Guide/index.html">http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html-single/Software_Collections_Guide/index.html</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>