2009/11/29 M.-A. Lemburg
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