<div dir="ltr">Btw, it's not a dependency conflict issue. If we install python dependencies via pip, it's okay to be with foo>=1.5.0 in the past, but not now maybe (oslo.util -> oslo_util breaks nearly everything). Maybe we need a requirements.txt as release like:<div><br><div>foo==1.5.0</div><div>bar==2.1.0</div><div><br></div><div>not</div><div><br></div><div>for>=1.5.0</div><div>bar>=2.0.0</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 27, 2015 at 3:32 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 27 August 2015 at 02:00, Gareth <<a href="mailto:academicgareth@gmail.com">academicgareth@gmail.com</a>> wrote:<br>
> Hey guys,<br>
><br>
> I have a question about dependencies. There is an example:<br>
><br>
> On 2014.1, project A is released with its dependency in requirements.txt<br>
> which contains:<br>
><br>
> foo>=1.5.0<br>
> bar>=2.0.0,<2.2.0<br>
><br>
> and half a year later, the requirements.txt changes to:<br>
><br>
> foo>=1.7.0<br>
> bar>=2.1.0,<2.2.0<br>
><br>
> It looks fine, but potential change would be upstream version of package foo<br>
> and bar become 2.0.0 and 3.0.0 (major version upgrade means there are<br>
> incompatible changes).<br>
><br>
> For bar, there will be no problems, because "<2.2.0" limit the version from<br>
> major version changes. But with 2.0.0 foo, it will break the installation of<br>
> 2014.1 A, because current development can't predict every incompatible<br>
> changes in the future.<br>
<br>
</span>Correct. But actually bar is a real problem for single-instance binary<br>
distributors - like Debian family distributions - where only one<br>
version of bar can be in the archive at once. For those distributions,<br>
when bar 3 comes out, they cannot add it to the archive until a new<br>
release of project A happens (or they break project A). They also<br>
can't add anything to the archive that depends on bar > 2.2.0, because<br>
they can't add bar. So it leads to gridlock. We are now avoiding<br>
adding and won't except in exceptional circumstances, such defensive<br>
upper bounds to OpenStack's requirements. When we /know/ that the<br>
thing is broken we may - if we can't get it fixed.<br>
<span class=""><br>
> A real example is to enable Rally for OpenStack Juno. Rally doesn't support<br>
> old release officially but I could checkout its codes to the Juno release<br>
> date which make both codes match. However even if I use the old<br>
> requirements.txt to install dependencies, there must be many packages are<br>
> installed as upstream versions and some of them breaks. An ugly way is to<br>
> copy pip list from old Juno environment and install those properly. I hope<br>
> there are better ways to do this work. Anyone has smart ideas?<br>
<br>
</span>As Boris says, use virtualenvs. They'll solve 90% of the pain.<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font color="#444444">Gareth</font><div><font color="#444444"><br></font><div><i><font color="#444444">Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball</font></i></div><div><i><font color="#666666">OpenStack contributor, kun_huang@freenode</font></i></div><div><i><font color="#999999">My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me </font></i></div><div><i><font color="#999999">and I'll donate $1 or ￥1 to an open organization you specify.</font></i></div></div></div></div>
</div>