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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
