Open Stack

Excerpts from Jeremy Stanley's message of 2017-07-14 15:17:52 +0000:
> On 2017-07-14 10:50:50 -0400 (-0400), Doug Hellmann wrote:
> > Excerpts from Jesse Pretorius's message of 2017-07-14 08:32:48 +0000:
> > > FYI if you see the following error in your job logs, you have the new setuptools to thank:
> > > 
> > > AttributeError: Distribution instance has no attribute 'install_requires'
> > > 
> > > I’ve registered https://github.com/pypa/setuptools/issues/1086 to track the issue, and very quickly got a response and there’s a PR up to resolve it.
> > > 
> > > In our case we saw this when downgrading setuptools to our known, good working version.
> > > 
> > > I’d like to suggest that we include setuptools, pip, wheel and other core packages in the upper constraints management process and that all the images built for jobs make use of it. The number of times that a new release of pip/setuptools has completely ground development to a halt for a day, sometimes more, is a little too frequent for my liking.
> > > 
> > > IIRC we’d need to just change the u-c generation output from ‘pip freeze’ to ‘pip freeze –all’ for the output to include the versions for pip, setuptools and wheel. Then, with that spec, pip can be installed using u-c like so:
> > > 
> > > CURL_CMD="curl --silent --show-error --retry 5"
> > > OUTPUT_FILE="get-pip.py"
> > > ${CURL_CMD} https://bootstrap.pypa.io/get-pip.py > ${OUTPUT_FILE} ||\
> > >     ${CURL_CMD} https://raw.githubusercontent.com/pypa/get-pip/master/get-pip.py > ${OUTPUT_FILE}
> > > 
> > > python ${OUTPUT_FILE} pip setuptools wheel -c upper-constraints.txt
> > > 
> > > That will ensure a consistent, known good version set is installed and will also cater for the situation where the primary URL for get-pip.py is down (as happens sometimes).
> > > 
> > 
> > I know we made the explicit decision not to pin setuptools, but I don't
> > remember the motivation. Was it a technical decision (we can't) or
> > because it seemed like a bad idea (we want to ensure we have the
> > latest)?
> 
> Chicken and egg. Once you get to the point where pip can enforce
> constraints, you already have a version of setuptools installed. And
> as evidenced by, for example, this current bug you would just end up
> breaking on the downgrade trying to replace your existing broken
> version with whatever version is requested. Also you would need a
> separate phase to upgrade/downgrade setuptools separate from other
> packages using it.

That makes sense.

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.

Doug