> On Sep 18, 2014, at 7:43 AM, Thomas Goirand <z...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
