[Distutils] RFC PEP 386 : Version comparisons

[Tarek Ziadé]

On Mon, Jul 6, 2009 at 10:28 AM, Floris
Bruynooghe<floris.bruynooghe at gmail.com> wrote:
> On Sun, Jul 05, 2009 at 02:40:37PM -0400, P.J. Eby wrote:
>> At 02:12 PM 7/4/2009 -0400, Tres Seaver wrote:
>>> - -1.  I would rather exclude some use cases (post releases), than drop
>>> standardization altogether.
>>
>> And some people are the exact opposite, which means there's no
>> consensus...  and thus no way to proceed.
>
> I was under the impression that .devX and .postX where accepted, but
> it got messy when .postX.devX got used.  But AFAIC (I'm not re-reading
> the entire thread now) it was stated that .postX.devX was not actually
> required (and if it was required just allowig exactly one each and it
> that order was sufficient).
>
> Also there is little harm in allowing .postX.devX you can simply
> ignore it and use simple 1.0.0 if that's all you want (I for one would
> ignore any .postX stuff).  As Tres says in another mail on this
> thread, what's important is that you can compare versions of another
> project and know what to expect as an outcome instead of hoping that
> all package managers using your version will make sense out of it.

Which means that *all* package managers will have to use the same standard, or
at least a compatible standard. And that all edge cases of each standard
will still have to work when they are used and compared in distutils.

I am not saying it's a bad thing, I am just saying that this should
not be enforced
by distutils because  :

- distutils doesn't have to compare versions (it's not a package manager)
- some developers won't buy that standard and use their own ways,
their own package manager

For the latter, should we forbid those developers the usage of the
requires-* fields ? Or should we let them
use those fields and let each package manager decide how to compare
the versions ?

Of course verlib can be added in distutils and provided as the default
cmp(), and we can state
in PEP 345 that's it's the default cmp() provided, and promote its usage.

But I'm not comfortable about forcing people to use that scheme, and
about writing in PEP 345 something
like 'you HAVE to be compatible with that scheme or your can't use that field'.

I am very uncomfortable with the word 'forbid' that has been used in
this thread.

Here's my updated proposal:

- add verlib in distutils; without the pos/dev stuff (and after
another round of re-work/feedback)
- add in PEP 345 the Requires field(s)
- say in PEP 345 that is *strongly encouraged* to use
distutils.verlib, but that a third-party package manager can use his
own.
  (in any case this will be possible so...)

Tarek