Open Stack

> On Sep 18, 2014, at 12:29 PM, Clint Byrum <clint at fewbar.com> wrote:
> 
> Excerpts from Donald Stufft's message of 2014-09-18 07:30:27 -0700:
>> 
>>> 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.
>> 
> 
> There's also 3) fork requests, which is the democratic way to vote out
> an upstream that isn't supporting the needs of the masses.
> 
> I don't think we're anywhere near there, but I wanted to make it clear
> there _is_ a more extreme option.

Technically that’s just a specific case of option 1) ;)

But yes that’s a thing Openstack can do.

> 
>> 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.
>> 
> 
> To be clear, I think we should keep using requests. But we should lend
> our influence upstream and explain that our users are required to deal
> with this in a way that perhaps hasn't been considered or given the
> appropriate priority.

I think that’s completely reasonable. I don’t think there’s going to be much movement,
I’ve had this argument with Kenneth on more than one occasion and he’s very happy
with his decision to vendor urllib3, but hey maybe Openstack would have better luck.

---
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/595794bc/attachment.html>