Open Stack

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.

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