Open Stack

On 09/18/2014 08:22 AM, Morgan Fainberg wrote:
> I think that all of the conversation to this point has been valuable,
> the general consensus is vendoring a library is not as desirable as
> using it strictly as a dependency. It would be nice in a perfect
> world if vendoring wasn’t and issue, but in this case I think the
> root of the matter is that Debian un-vendors urllib3 and we have
> referenced the vendored urllib3 instead of installing and utilizing
> urllib3 directly.
> 
> This poses at least one problem for us: we are not able to guarantee
> we’re using the same urllib3 library as requests is. I am unsure how
> big of a deal this ends up being, but it is a concern and has brought
> up a question of how to handle this in the most appropriate and
> consistent way across all of the distributions we as OpenStack support. 
> 
> Does this make requests a bad library we should toss aside for
> something else? Instead of being concerned with the reasons for
> vendoring urllib3 (or un-vendoring it) we should shift the conversation
> towards two questions:
> 
> 1. Is it a real issue if the version of urllib3 is mismatched between
> our client libraries and requests? 
> 2. If it is a real issue how are we solving it?

The main issue is that urllib3 in requests, as other pointed out, is not
up-to-date, and will not be updated. In fact, that's the main reason why
the upstream authors of requests are vendorizing: it's because they
don't want to carry the burden of staying up-to-date.

And then, there's incompatibilities and divergences that appear, leading
to all sorts of unexpected issues, like one thing working with pip, but
not with the packages. This kind of issues are very hard to understand
and debug. Distributions may report the issue upstream, then upstream
will say "but it's working for me", and then we may loose a lot of time.
This happened already, and may happen again if we don't care enough.

> Obviously we can work with the requests team to figure out the best
> approach.

There's only a single approach that works: have the requests upstream
authors to stop embedding foreign code, and use the dependency instead.

> We should focus on the solution here rather than continuing
> down the path of whether requests should/shouldn’t be vendoring it’s
> dependencies since it is clear that the team has their reasons and
> does not want to switch to the dependency model again.

I'm sure they have tons of wrong reasons. If they don't want to change
anything, then we can only try to work around the issue, and never use
the embedded version.

Thomas Goirand (zigo)