[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 14:30:27 UTC 2014


> On Sep 18, 2014, at 10:18 AM, Clint Byrum <clint at fewbar.com> wrote:
> 
> Excerpts from Donald Stufft's message of 2014-09-18 04:58:06 -0700:
>> 
>>> On Sep 18, 2014, at 7:54 AM, Thomas Goirand <zigo at debian.org> wrote:
>>> 
>>>> 
>>>> Linux distributions are not the end be all of distribution models and
>>>> they don’t get to dictate to upstream.
>>> 
>>> Well, distributions is where the final user is, and where software gets
>>> consumed. Our priority should be the end users.
>> 
>> 
>> Distributions are not the only place that people get their software from,
>> unless you think that the ~3 million downloads requests has received
>> on PyPI in the last 30 days are distributions downloading requests to
>> package in their OSs.
>> 
> 
> Do pypi users not also need to be able to detect and fix any versions
> of libraries they might have? If one has some virtualenvs with various
> libraries and apps installed and no --system-site-packages, one would
> probably still want to run 'pip freeze' in all of them and find out what
> libraries are there and need to be fixed.
> 
> Anyway, generally security updates require a comprehensive strategy.
> One common comprehensive strategy is version assertion.
> 
> Vendoring complicates that immensely.

It doesn’t really matter. PyPI doesn’t dictate to projects who host there what
that project is allowed to do except in some very broad circumstances. Whether
or not requests *should* do this doesn't really have any bearing on what
Openstack should do to cope with it. The facts are that requests does it, and
that people pulling things from PyPI is an actual platform that needs thought
about.

This leaves Openstack with a few reasonable/sane options:

1) Decide that vendoring in requests is unacceptable to what Openstack as a
   project is willing to support, and cease the use of requests.
2) Decide that what requests offers is good enough that it outweighs the fact
   that it vendors urllib3 and continue using it.

If the 2nd option is chosen, then doing anything but supporting the fact that
requests vendors urllib3 within the code that openstack writes is hurting the
users who fetch these projects from PyPI because you don't agree with one of
the choices that requests makes. By all means do conditional imports to lessen
the impact that the choice requests has made (and the one that Openstack has
made to use requests) on downstream distributors, but unconditionally importing
from the top level urllib3 for use within requests is flat out wrong.

Obviously neither of these options excludes the choice to lean on requests to
reverse this decision as well. However that is best done elsewhere as the
person making that decision isn't a member of these mailing lists as far as
I am aware.

---
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/8bf48b55/attachment.html>


More information about the OpenStack-dev mailing list