[openstack-dev] olso-config dev requirement

Doug Hellmann doug.hellmann at dreamhost.com
Tue Jul 16 15:42:20 UTC 2013


On Tue, Jul 16, 2013 at 7:58 AM, Mark McLoughlin <markmc at 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 <mordred at 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
> > > 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.

Doug


>
> Cheers,
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130716/6ec8e67c/attachment.html>


More information about the OpenStack-dev mailing list