[openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)
Donald Stufft
donald at stufft.io
Thu Sep 18 11:47:54 UTC 2014
> On Sep 18, 2014, at 7:43 AM, Thomas Goirand <zigo at debian.org> wrote:
>
> On 09/18/2014 04:01 PM, Flavio Percoco wrote:
>> After having gone through the whole thread and read all the concerns,
>> problems and reasonings, I think we should stick to requests as-is for
>> now and deal with this particular issue.
>>
>> Regardless of the vendorized urllib3 package, I believe requests is a
>> good library with an easy-to-consume API and it has solved several
>> problems throughout OpenStack. Not to mention it's also helpped with
>> making OpenStack more consistent. We've put a lot of effort to get to
>> this point and I don't think we should revert all that because of the
>> vendorized `urllib3` package.
>>
>> Cheers,
>> Flavio
>
> I, at least, haven't suggested that we stop using requests. Just that we
> don't internally use any of the requests.packages.* stuff.
>
> The rest of the debate about the good or bad things with vendorizing,
> even if it is my view that it's a really bad thing, is IMO not
> interesting for the OpenStack project.
I don’t believe that’s a good idea. If you’re wanting to use urllib3 in order
to interact with requests than you *should* be using requests.packages.urllib3,
to do anything else risks having two different versions of urllib3 primitives at
play in one subsystem.
It’s not even completely possible in the case that prompted this thread originally
since the reason requests.packages.urllib3 was being imported from was so that
there could be an is instance() check against one of the classes. If that wasn’t
imported from requests.packages.urllib3 but instead from just urllib3 than the
isinstance check would always fail.
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140918/012cfb5a/attachment.html>
More information about the OpenStack-dev
mailing list