Hey everybody!

I just put up a couple of patches here:

https://review.openstack.org/#/q/topic:ksa-requests

that remove direct depends from client libs on requests, which leave them to rely on keystoneauth for their requests dependency.

The reason I pushed these up is that we're seeing bug reports from users out there that they'll install a set of python-*clients, then try to use something with entrypoints and pkg_resources barfs at them.

This in turn is caused by _some_ of the clients having made releases with a new version exclusion placed on requests but others not having made that, and then the ones that haven't released with the exclusion yet happen to be the ones from which pip decides to install requests - leading to a version of requests being installed that conflicts with the stated version string of some of our client libs. (yay! :( )

So my general proposal is that since all of our client libs use keystoneauth for their REST interactions anyway (yay for real), that we rely on keystoneuath for installation of requests. This way if we need to get a fix out that involves blocking a version of requests, we simply need to land it in ksa and release ksa - which is also low impact because ksa has an extremely strict policy on changes and backwards compat.

There is a similar issue that currently exists with Babel, so I'll also send a few patches out. There is a MUCH LARGER overall issue at work here that Doug Hellmann has a proposal up for fixing in a real way. I don't think we should spend an excessive amount of time obsessing about trying to shrink transitive dependency chains like this and instead we should just work on Doug's thing. But requests is, well, it's kind of essential to all the client libs - so it seems like a fairly simple way to fix something that's breaking our users right now.

Monty

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to