[Distutils] Differences in PEP386 and setuptools

Donald Stufft donald.stufft at gmail.com
Thu Sep 27 19:00:10 CEST 2012


On Thursday, September 27, 2012 at 11:59 AM, Toshio Kuratomi wrote:
> setuptools allows any random string into the versions. Certain strings have
> special meaning. Unknown strings are lexicographically sorted. Rereading
> this section of the PEP
> http://www.python.org/dev/peps/pep-0386/#caveats-of-existing-systems
> 
> will give you the background on problems with the setuptools concept.
> For part of the rationale about .dev, the first paragraph of the rationale
> is important. setuptools allowed too many things to be allowed into
> versions. Remembering how the specialcases mix with the lexicographic
> sorting lead to confusion when some project starts working with non-standard
> version strings. So one of the goals of PEP 386 was to make a small,
> discrete number of legal version strings.

No arguments here on the need of this goal. 
> 
> Keeping that in mind, these are the alpha tags that PEP386 allows:
> a, b, c, rc, .post, .dev
> 
> * a, b, c, and rc are the typical alpha beta release candidate tags. We
> debated whether to allow the single letter versions or the long versions
> "alpha", "beta", "rc". In the end, which set of tags was used was
> a bikeshed argument so it was chosen by PEP-author decree. I personally
> felt that having both "c" and "rc" was counter to the goals of the PEP but
> we at least agreed that "rc" would intuitively sort after "c" so it wasn't
> as bad as having both "alpha" and "a" where there would be no intuitively
> correct sorting.
> * For .post there was a desire to have a tag that sorted after release.
> Choice of .post for the bikeshed color was not controversial.
> * For .dev there was a desire to have a tag that sorted before release.
> Choice of .dev for the bikeshed was debated but in the end it was
> a bikeshed and we were all very tired of it. I'm not sure at this point
> who was championing .dev over .pre or similar or what their rationale was.

Yes I've read this, but sadly all it says about the issue really is "I don't remember". 
> I would be for renaming .dev to .pre[1]_ but I would be against the rest of this
> proposal. Having one and only one way to spell things was one of the goals
> of the pep. Having two post release tags that don't already have a defined
> meaning leads to confusion about what the ordering should be:

dev (in my proposal, and in the way I've seen it used) isn't a post release tag,
it is a separate release at the same level as alpha, beta, rc, final, and it's
meaning tends to be "this is the in development version of what will become
release X.Y", so foo-1.0dev1 means the first development release of what
will become foo-1.0, (just like foo-1.0a1 is the first alpha release of what
will become foo-1.0).

With the current layout (and with your changes to the proposal) there is no
good way to have a development version. With the current layout the best
approximation you can get is 1.0a1.dev1 (similarly with your changes it would
be 1.0a1.pre1).

On the surface 1.0a1.dev1 looks like it might be alright, but my issues with it:

    1. It's not intuitive (at least not to me, development snapshots have
        always come before alphas in my mind)
    2. Goes against what is currently being used for either no good reason or
        a yet to be remembered good reason.
    3. Requires you to decide ahead of time if you're going to go from dev
        to alpha, or straight to a beta/candidate/final. (This is something that
        most small projects don't have set in stone).
     4. It's semantics are different, this is a development release of
         1.0a1 as opposed to a development release of the 1.0 version.
     5. It's just plain ugly.


So to be clear my proposal would be:

    1.0dev1 < 1.0a1 < 1.0b1 < 1.0c1 < 1.0.pre1 < 1.0 < 1.0.post1

as opposed to the current:

    1.0a1 < 1.0b1 < 1.0c1 < 1.0.dev1 < 1.0 < 1.0.post1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120927/9c08e2dc/attachment.html>


More information about the Distutils-SIG mailing list