[Distutils] Library instability on PyPI and impact on OpenStack

[Daniel Holth]

On Tue, Mar 5, 2013 at 7:50 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> 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!".

It will have exactly the opposite effect. Semver is awesome because it
encourages the developer to first define an API at all, then think
about whether each new release breaks the API, and last encode that
information in the version number instead of incrementing each
component by whatever random number feels right. All that extra
thinking will lead to better APIs.

You will be amazed at how much backwards compatible cruft some
developers will keep around rather than endure the psychological
anguish of bumping the major version number.