[Distutils] PEP 386 status - last round here ?

[P.J. Eby]

At 02:34 PM 11/29/2009 +0100, M.-A. Lemburg wrote:
>P.J. Eby wrote:
> > At 08:11 PM 11/28/2009 +0100, M.-A. Lemburg wrote:
> >> Tarek Ziadé wrote:
> >> > On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> >> >> Here's another take at a minimal change to the format which
> >> >> includes the things we discussed, adds a few more aliases
> >> >> for the "post" and "dev" markers and also adds optional
> >> >> underscores for more readability.
> >
> > Please don't add underscores to the syntax -- they will cause problems
> > with the filename escaping and parsing used today by setuptools and
> > compatible tools, and will produce inconsistent comparisons between
> > "rational" versions and the version schemes supported by setuptools.
> >
> > Ideally, it would be best to keep PEP 386 versions a strict subset of
> > setuptools-supported versions, to minimize migration difficulties.
>
>Filename parsing is a bad idea to begin with.

Practicality beats purity.

>Frankly, we are defining a standard for *distutils* and new packages
>here - so I'm not sure in what way setuptools compatibility can be
>used as argument for limiting the readability of a new standard.
>OTOH, I'm sure that by the time distribute can take over the role
>of setuptools, such limitations will have been lifted.

Unless we're talking about strictly Python 3 here (in which case all 
bets are off and compatibility isn't a prime concern) Distribute is 
limited by the need to be able to consume setuptools-based packages, 
or it loses a key user incentive (i.e., its "just works"-ness).


>Besides, setuptools users can, of course, continue to use version
>strings without embedded underscores.

Setuptools users also consume other people's packages, which means 
they will wind up with bad version comparisons in that case.  And 
Distribute can't work around this unless it escapes underscores as 
some other character when it makes files for consumption by those 
tools, since it will otherwise lose the ability to parse those 
versions when they come back in.

If you want mass uptake of a standard, you need to take these sort of 
things into consideration; incentive engineering is not optional when 
you want grass-roots support for an independently-created standard.

WSGI and setuptools have been widely adopted in spite of their 
technical and ideological flaws, because they had good incentive engineering.

Or, in other words, because practicality beats purity, every single time.