Open Stack

On 9/17/14, 9:24 PM, "Thomas Goirand" <zigo at debian.org> wrote:

>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.

How involved are you with requests’ development process? You must not be
very involved because this is the exact opposite reason of why we vendor.
More often that not we pull in urllib3 to get unreleased features that we
build upon for our newest release. If what you said was true, 2.4.{0,1}
would not have the ability to pass socket level options that nova client
decides it wants to set. If we were pinning to an old version of urllib3,
this feature would never be possible. We vendor, because in order to
provide these features we don’t want to have to support the ancient
versions of urllib3 that used to cause us headaches on platforms like
Debian.

>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.

The fact is, anyone who doesn’t run their tests in Devstack runs them in a
virtual environment. The line you’re complaining about is actually correct
in that context (the context where pip installs requests). That said, the
test should instead use a conditional import and fallback to the vendored
copy.