[Distutils] PEP 386 status - last round here ?

M.-A. Lemburg mal at egenix.com
Wed Nov 25 21:04:51 CET 2009


Tarek Ziadé wrote:
> 2009/11/25 M.-A. Lemburg <mal at egenix.com>:
>> M.-A. Lemburg wrote:
>>> Could we extend the pseudo-format of the versions a little to also
>>> include variants which use more than just one character and also
>>> allow hyphens and spaces to be used for additional clarity ?
>>>
>>> VERSION_RE = re.compile(r'''
>>>     ^
>>>     (?P<version>\d+\.\d+)          # minimum 'N.N'
>>>     (?P<extraversion>(?:\.\d+)*)   # any number of extra '.N' segments
>>>     (?:
>>>         [- .]*
>>>         (?P<prerel>[a-z]+)        # 'a'=alpha, 'b'=beta, 'c'=release candidate
>>>         [- .]*
>>>         (?P<prerelversion>\d+(?:\.\d+)*)
>>>     )?
>>>     (?P<postdev>
>>>         ([- .]*post[- .]*(?P<post>\d+))?
>>>         ([- .]*dev[- .]*(?P<dev>\d+))?
>>>     )?
>>>     $''', re.VERBOSE + re.I)
>>>
>>> The pre-release marker would then be interpreted in alphabetical
>>> order, ie. 'alpha' < 'beta' < 'rc'.
>>>
>>> This minor change would broaden the scope of the scheme somewhat
>>> and make it more compatible to what's being used outside the
>>> python-dev sphere (esp. with respect to 'c' standing for release
>>> candidate... unless you happen to read it as gamma ;-).
>>
>> ... and even python-dev has switched to "rc" for these:
>>
>> http://www.python.org/dev/peps/pep-0361/
>>
>>> The added optional hypens and spaces make the versions more
>>> readable, IMHO.
> 
> The goal of the scheme is to propose a unique standard, together with
> the "suggest_rational_version" API that allow transforming an
> almost-rational version to a rational version. IOW, having several
> ways of defining separators would
> make the version scheme loose.  I have the feeling this would have a
> negative impact but I don't have a strong example in mind yet.

So perhaps this is just a misunderstanding on my part regarding
the intended use of the new standard "rational" version format.

If the "rational" format is just used internally by distutils to
compare resource versions, then why do we have to define
the format in a PEP ?

If all external version strings (e.g. from the setup() call
or PyPI) first go through suggest_rational_version(), then
why not define its supported set of version strings in the PEP
instead ?

I was under the impression that developers should be encouraged
to use the new "rational" version format directly in their
package versions - without a helper in between.

IMHO, that intent would go a much longer way, since the user
visible version strings would then follow this standard.

However, since distutils only needs to be able to compare the
versions, without actually knowing what 'alpha', 'beta'
and 'rc' mean, I don't (currently) see a reason not to allow
complete words in the version string.

> Now, suggest_rational_version is meant to transform those close-enough
> versions strings into working strings,
> 
> Example with "rc" vs "c":
> 
>>>> from verlib import suggest_rational_version
>>>> suggest_rational_version('2.4rc1')
> '2.4c1'
> 
> Meaning that a package manager could be permissive and use those
> almost-rational form with this API. So if we get
> suggest_rational_version work with hypens and spaces as you are
> suggesting, that could be a solution.
> 
> Now, about the "c" choice. "c" was preferred to "rc" here to avoid
> using "r" which has a strong Subversion connotation.

I don't believe that any developer who knows that revisions
are marked as "r123" would mistake "rc" for a revision marker ;-)

> Next, hyphens were removed because they are avoided in some systems
> like Debian or Ubuntu,  and have a very specific meaning in
> setuptools.

That's a good point.

RPM doesn't like hyphens in versions either... so forget the hyphen
and spaces idea.

I'd still like to write "1.2beta3" and "2.1rc3", though, and be
standards compliant :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 25 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


More information about the Distutils-SIG mailing list