[Distutils] PEP 426, round 733 ;)

[Erik Bray]

On Tue, Feb 5, 2013 at 9:08 AM, Daniel Holth <dholth at gmail.com> wrote:
> On Tue, Feb 5, 2013 at 7:54 AM, Donald Stufft <donald.stufft at gmail.com>
> wrote:
>>
>> On Tuesday, February 5, 2013 at 5:35 AM, a.cavallo at cavallinux.eu wrote:
>>
>> Ideally it would be something that connects to the source revision number
>> (as in
>> subversion) or the integral id or even a timestamp (that's what an
>> exported
>> version must be).
>>
>> Timestamp or reversion number is not overall useful number for a version
>> and
>> here's why: Django (for example) maintains older versions for a set period
>> of time,
>> If you do it via timestamps than 1.1.1 which happens to be released after
>> 1.2.0 (because
>> of a security issue or glaring bug) will be considered "newer". Handwaving
>> the problem
>> away with a source revision number or timestamp ignores a fundamental
>> property
>> of a version
>
>
> What pkg_resources does for sorting is to append "final" for sorting. So the
> sorting is really just a, b, c, f. This scheme has been important for 8+
> years now. PEP 386, from 2009, narrows the allowed versions. Now the salient
> part of PEP 386 has been incorporated into Metadata 1.3.
>
> 1.0.0a0
> 1.0.0b0
> 1.0.0c0 ~= 1.0.0rc0
> 1.0.0 == 1.0.0f
>
> The "marketing pre-release" feature exists to allow publishers to put
> immature versions of their software on pypi where they can be easily
> downloaded. Recently SQLAlchemy did this but had to delete the beta release
> from pypi because too many deployments upgraded to an unstable version
> without realizing it. Once the tools are updated it will be easy to install
> a beta release with pip if and only if you specifically ask for it.

Yes, this is incredibly useful and I'm glad it was incorporated into
this PEP.  For the Astropy project for example we recently release
version 0.2b2 and we absolutely want to be able to put it on PyPI for
users to test out.  But as the current situation stands we can't do
that because 0.2b2 then becomes the "latest" version, and the one the
gets installed when users expecting the latest stable release do `pip
install astropy`.

So instead we've just been adding the pre-final release to testpypi
and pointing people there. And that's not really meant to be a
reliable service.  So...yeah.  A++ for adding this requirement.