On 07/16/2013 11:42 AM, Doug Hellmann wrote: > > > > On Tue, Jul 16, 2013 at 7:58 AM, Mark McLoughlin <[email protected] > <mailto:[email protected]>> wrote: > > On Mon, 2013-07-15 at 14:28 -0400, Doug Hellmann wrote: > > On Mon, Jul 15, 2013 at 11:03 AM, Monty Taylor > <[email protected] <mailto:[email protected]>> 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. Monty _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
