[Distutils] Library instability on PyPI and impact on OpenStack

[Mark McLoughlin]

On Tue, 2013-03-05 at 07:34 -0500, Donald Stufft wrote:
> On Tuesday, March 5, 2013 at 7:27 AM, Mark McLoughlin wrote:

> > On Tue, 2013-03-05 at 17:56 +1000, Nick Coghlan wrote:

...
> > > I will note that making this kind of idea more feasible is one of
> > > the
> > > reasons I am making "compatible release" the *default* in PEP 426
> > > version specifiers, but it still needs people to actually figure
> > > out
> > > the details and write the code.
> > 
> > 
> > I still think that going down this road without the parallel
> > installs
> > issue solved is a dangerous move for Python. Leaving aside pain for
> > distros for a moment, there was a perception (perhaps misguided)
> > that
> > Python was a more stable platform that e.g. Ruby or Java.
> > 
> > 
> > If Python library maintainers will see PEP426 as a license to make
> > incompatible changes more often so long as they bump their major
> > number,
> > then that perception will change.
> I still don't really see how this is related to PEP426 unless PEP426
> has gotten
> a lot larger since I last looked at it. Where in particular a
> distribution gets
> installed is left up to the installers to sort out. And making sure
> that the installed
> versions exist in sys.path is similarly out of scope for PEP426.

Sorry, maybe I'm being obtuse.

I can see people read PEP426 and thinking "oh, awesome! Python now has a
mechanism for handling incompatible API changes! Now I can get rid of
that crufty backwards compat code and bump my major number!".

My point is that it's (potentially) damaging to send that message to
library maintainers before Python has the infrastructure for sanely
dealing with parallel installs.

...

> > I think what you call "*actual* bundling" is what I think of as
> > "vendorisation" - i.e. where an app actually copies a library into
> > its
> > source tree?
> > 
> > 
> > By bundling, I mean that an app sees itself as in control of the
> > versions of its dependencies. The app developer fundamentally thinks
> > she
> > is delivering a specific stack of dependencies and her application
> > code
> > on top rather than installing just their app and running it on a
> > stable
> > platform.
> In this case the app would be one unit and an upgrade in one of the
> bundled dependencies would require a new version of the App. In my
> mind when an app either bundles or vendorizes they take responsibility
> for those dependencies and making sure they are up to date because
> they are now part of the logical unit that is the app.

Right, exactly - the idea Nick lays out allows the dependencies to be
managed by the system platform maintainer. That would be a huge
improvement over bundling.

Cheers,
Mark.