[Distutils] PEP 386 status - last round here ?

[Tarek Ziadé]

2009/11/29 M.-A. Lemburg <mal at egenix.com>:
[..]
>>
>> 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. The meta data
> incorporated into file names should be read from a meta data file
> or database instead, with the filename just being another parameter
> in the set of meta data parameters.

Notice that the metadada files added during installation are the ones
that will be used
to query installed distributions (see PEP 376)

Their syntax is currently :  name + '-' + version + '.egg-info' , with
all occurences of "-" in the name being escaped by "_".

So I don't see any technical problem in using "-" in the version, as
long as the first "-" in the egg-info
name can be used to be able to extract the name and version of the project.

*But*, on a second thought,  I don't see any problem in completely
removing the version from
the egg-info filename in PEP 376, since looping on *.egg-info files
suffices for our APIs, and since
we said that we didn't want to support multiple versions.

>
> 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.
>

Yes, Distribute will follow all PEPs as soon as they are accepted,

Last, as I said in a previous mail, I tend to agree with the people
who said that we should stick with only one way to write the version
scheme for the sake of clarity. e.g. dropping aliases and picking
*one* way to write the markers after major.minor.micro.

I would tend to pick the same scheme than Python for the pre-releases
(and c + rc):

    N.N[.N][(a|b|c|rc)N]

And, for the post/dev markers I think dots are OK for readability,

Tarek