[openstack-dev] Requests + urllib3 + distro packages

Cory Benfield cory at lukasa.co.uk
Fri Oct 9 13:58:36 UTC 2015


> On 9 Oct 2015, at 14:40, William M Edmonds <edmondsw at us.ibm.com> wrote:
> 
> Cory Benfield <cory at ...> writes:
> > > The problem that occurs is the result of a few interacting things:
> > >  - requests has very very specific versions of urllib3 it works with.
> > > So specific they aren't always released yet.
> >
> > This should no longer be true. Our downstream redistributors pointedout to us
> > that this  was making their lives harder than they needed to be, so it's now
> > our policy to only  update to actual release versions of urllib3.
> 
> That's great... except that I'm confused as to why requests would continue to repackage urllib3 if that's the case. Why not just prereq the version of urllib3 that it needs? I thought the one and only answer to that question had been so that requests could package non-standard versions.
> 

That is not and was never the only reason for vendoring urllib3. However, and I cannot stress this enough, the decision to vendor urllib3 is *not going to be changed on this thread*. If and when it changes, it will be by consensus decision from the requests maintenance team, which we do not have at this time.

Further, as I pointed out to Donald Stufft on IRC, if requests unbundled urllib3 *today* that would not fix the problem. The reason is that we’d specify our urllib3 dependency as: urllib3>=1.12,<1.13. This dependency note would still cause exactly the problem observed in this thread.

As you correctly identify in your subsequent email, William, the core problem is mixing of packages from distributions and PyPI. This happens with any tool with external dependencies: if you subsequently install a different version of a dependency using a packaging tool that is not aware of some of the dependency tree, it is entirely plausible that an incompatible version will be installed. It’s not hard to trigger this kind of thing on Ubuntu. IMO, what OpenStack needs is a decision about where it’s getting its packages from, and then to refuse to mix the two.

Cory
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151009/80add1d8/attachment.pgp>


More information about the OpenStack-dev mailing list