On Tue, 2013-07-16 at 13:37 -0400, Monty Taylor wrote: > > On 07/16/2013 11:42 AM, Doug Hellmann wrote: > > > > > > > > On Tue, Jul 16, 2013 at 7:58 AM, Mark McLoughlin <mar...@redhat.com > > <mailto:mar...@redhat.com>> wrote: > > > > On Mon, 2013-07-15 at 14:28 -0400, Doug Hellmann wrote: > > > On Mon, Jul 15, 2013 at 11:03 AM, Monty Taylor > > <mord...@inaugust.com <mailto:mord...@inaugust.com>> wrote: > > > > > > > I was looking in to dependency processing as part of some pbr > > change, > > > > which got me to look at the way we're doing oslo-config dev > > requirements > > > > again. To start, this email is not about causing us to change > > what we're > > > > doing, only possibly the mechanics of what we put in the > > > > requirements.txt file- or to get a more specific example of what > > we're > > > > solving so that I can make a test case for it and ensure we're > > handling > > > > it properly. > > > > > > > > Currently, we have this: > > > > > > > > -f > > > > > > > > > > > > http://tarballs..openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2..0a3 > > > > <http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3> > > > > oslo.config>=1.2.0a3 > > > > > > > > As the way to specify to install >- 1.2.0a3 of oslo.config. I > > believe > > > > this construct has grown in response to a sequence of issues, > > but it's > > > > complex and fragile, so I'd like to explore what's going on. > > > > > > > > The simplest answer would be simply to replace it with: > > > > > > > > http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz > > > > > > > > which will quite happily cause pip to install the contents of that > > > > tarball. It does not declare a version, but it's not necessary to, > > > > because the tarball has only one version that it is. Is there a > > problem > > > > we have identified where the wrong thing is happening? > > > > > > > > > > > I've tested that I get the right thing in a virtualenv if I make > > that > > > > change from pip installing a tarball, pip installing the > > requirements > > > > directly and python setup.py install. Is there anything I'm missing? > > > > > > > > Monty > > > > > > > > > > > > > Without the version specifier, we are relying on all projects to > > install > > > the right version from that tarball link when we run devstack, but > > we have > > > no guarantee that they are moving to new releases in lockstep. > > > > Yep, that's it. The thing to test would be if some projects have the > > 1.2.0a2 tarball link and an one has the 1.2.0a3 link because it depends > > on an API that's new in 1.2.0a3. > > > > > > It's worse than that. What gets installed will depend on the order > > devstack installs the projects and what their respective requirements > > lists say. It is possible to end up with compatible source code > > installed, but with a version number that setuptools thinks is not > > compatible based on projects' requirements. In that case, setuptools may > > not let us load plugins, so services will start but not actually work. > > Thank you. This is what I needed here. > > BTW - I put this up: > > https://review.openstack.org/#/c/35705/ > > To take a stab at installing our global requirements list first, and > then installing our projects in that environment. I also just made: > > https://review.openstack.org/#/c/37295/ > > Which would add oslo.config and oslo.messaging as git repos to the > devstack system, so that we can track trunk like we do with the other > projects.
Awesome, thanks - I've had that on my TODO list for weeks. It's probably a bit early about oslo.messaging, since nothing's using it yet ... but no harm in having it in there. Thanks again, Mark. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev