Open Stack

Excerpts from Ian Cordasco's message of 2014-09-18 07:35:10 -0700:
> On 9/18/14, 9: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.
> 
> Except that even OpenStack doesn’t pin requests because of how
> extraordinarily stable our API is. While you can argue that Kenneth has
> non-standard opinions about his library, Cory and I take backwards
> compatibility and stability very seriously. This means anyone can upgrade
> to a newer version of requests without worrying that it will be backwards
> incompatible. 
> 

All of your hard work is very much appreciated. I don't understand what
your assertion means though. We don't pin things. However, our users end
up "pinning" when they install via pip, and our distros end up "pinning"
when they deliver a version. Without any indication that urllib3 is in
the system, they will fail at any cursory version audit that looks for it.

I'm not saying either way is right or wrong either.. I'm suggesting
that this is a valid, proven method for large scale risk assessment,
and it is complicated quite a bit by vendored libraries.