[openstack-dev] [all] New setuptools release, and the world is broken

Doug Hellmann doug at doughellmann.com
Fri Jul 14 17:26:54 UTC 2017


Excerpts from Jeremy Stanley's message of 2017-07-14 16:18:04 +0000:
> On 2017-07-14 16:05:36 +0000 (+0000), Jesse Pretorius wrote:
> > On 7/14/17, 4:54 PM, "Doug Hellmann" <doug at doughellmann.com> wrote:
> [...]
> > > I wonder if we could convince the PyPA folks to allow get-pip.py
> > >    to take a version argument, so we could specify which version we want in
> > >    our jobs. We would still need a way to manage that version number, but
> > >    modifying get-pip.py would solve the bootstrapping issue.
> > 
> > It has been capable of this for quite some time. You can provide
> > both requirements And constraints.
> > 
> > python /opt/get-pip.py pip==9.0.1 setuptools==33.1.1 wheel==0.29.0
> > 
> > Or, far better, is to use constraints because it’ll ensure that
> > any dependent packages are also the right versions.
> > 
> > python /opt/get-pip.py pip setuptools wheel –constraint
> > http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt
> 
> Is there a mechanism to leverage this in tox or when invoking
> virtualenv? We don't run get-pip.py in most jobs because our images
> have pip/setuptools preinstalled to get around bootstrapping issues,
> though I suppose that could with some effort be moved into job
> runtime as a (very early) builder macro. Using constraints to
> control these during image generation doesn't make a whole lot of
> sense though as images are only rebuilt once a day and so tracking
> these in the constraints list won't be self-testing in that regard
> anyway.

I was thinking we would use an early stage builder to do it, too.

Doug



More information about the OpenStack-dev mailing list