[Distutils] Working toward Linux wheel support

[Nick Coghlan]

On 7 September 2015 at 09:42, Ben Finney <ben+python at benfinney.id.au> wrote:
> Nick Coghlan <ncoghlan at gmail.com> writes:
>
>> On 7 September 2015 at 02:09, Marcus Smith <qwcode at gmail.com> wrote:
>> > For example, down the road when there's Wheel 2.0, what's the "Current
>> > Specs" for wheel?
>>
>> Yes, but I think that's easy enough to handle by having a default URL
>> that always goes to the latest version of the spec, and moving
>> previous versions to URLs that include the version number.
>
> <modification severity="bikeshed">
> Or consistently publish each spec version to a predictable URL with the
> version number, and have the default URL *redirect* to whatever is the
> current-versioned spec.
> </modification>
>
> That way, the URL works as people expect, *and* the resulting
> destination gives a URL that (when inevitably copy-and-pasted) will
> retain its meaning over time.

Yes, ReadTheDocs does let us do that. However, there's actually a
problem with it, and it's this: it perpetuates the myth that it is
possible to publish viable packaging software without committing to
ongoing maintenance of that software to track changes to distribution
formats and user experience expectations.

Software distribution *fundamentally* involves interacting with the
outside world, and coping with evolving interoperability expectations.
Users should be able to grab the latest version of a packaging tool
and be confident that it supports the latest interoperability
standards (modulo a rollout window of a few weeks or maybe a few
months for tools designed for relatively slow moving environments).

This is the problem we always hit with distutils, and the one we still
regularly hit with the Linux distributions: their update and rollout
cycles are too slow, so they can't keep up with user expectations.

Thus, the mindset we want to cultivate amongst tool developers is "I
commit to ensuring my project gains support for the latest versions of
the Python packaging interoperability standards in a timely manner, as
well as supporting legacy versions of those standards for backwards
compatibility purposes", rather than "My project supports version 1.0
of the interoperability standards, and I might upgrade to 2.0 when
that happens. If I feel like it, and I have time. Maybe".

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia