On 2016-01-29 14:14:48 +0000 (+0000), gordon chung wrote: > trying to understand the situation here. isn't this all managed by > global-reqs? an incompatible pip and pbr were release so now we > can't build? were we the only project using downloadcache (i don't > recall us doing anything unique in our tox file)?
The tox.ini for Ceilometer stable/kilo was adding a downloadcache inherited by all its environments which caused tox to add --download-cache to all pip install invocations. While deprecated in pip 6 (and removed from the tox.ini during the Liberty cycle), this worked up until pip 8 dropped that option from its command-line parser. Due to unfortunate timing, the last commit on stable/liberty was tested with pip 7 and merged, but the 2015.1.2 tag for that commit was pushed after pip 8 was released and so tox was no longer able to work with the tagged commit. A number of workarounds were tried, but ultimately the explicit addition of -U (upgrade) to pip calls in tox.ini prevented my attempts to temporarily pin to earlier versions of pip within the calling script. > i would prefer a release to be made as there was a performance > backport made. what is the effort required to push tarball > generated outside of jenkins? any drawbacks? [...] The steps followed by tox could be emulated manually, with the addition of forcing a pip 7 install, and the result would then be copied via scp to tarballs.openstack.org by one of our Infra root admins. The drawbacks mostly come down to needing to apply some additional scrutiny to the generated tarball before pronouncing it viable, and the need to place trust in a manual process slightly inconsistent with our usual sdist generation mechanisms. -- Jeremy Stanley __________________________________________________________________________ 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
