[Distutils] RFC PEP 386 : Version comparisons

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziadé wrote:
> On Sun, Jul 5, 2009 at 6:26 PM, Tres Seaver<tseaver at palladion.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Tarek Ziadé wrote:
>>> On Sat, Jul 4, 2009 at 8:12 PM, Tres Seaver<tseaver at palladion.com> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Tarek Ziadé wrote:
>>>>
>>>>> back to that discussion, after re-reading all the threads I have a proposal :
>>>>>
>>>>> 1- let's add as we said "install_requires" in PEP 345 and describe in
>>>>> it that people can define requirements,
>>>>>   but without giving them rules for the version schemes.
>>>>>
>>>>>   We will just write in that PEP that it's up to the *dependency
>>>>> manager* (pip, setuptools, zc.buildout, etc)
>>>>>   to provide a cmp() for the version.
>>>>>
>>>>>   The only rule will be that each dependency is described like this :
>>>>>
>>>>>      dist_name [<|>|==|!=|>=|<=] version
>>>>>
>>>>>   where version is free and dist_name in [a-zA-Z0-9]
>>>>>
>>>>> 2- let's drop PEP 386 completely
>>>> - -1.  I would rather exclude some use cases (post releases), than drop
>>>> standardization altogether.
>>> Would you be OK to say in PEP 345 that a suggested tool to compare
>>> versions could be
>>> verlib (released as a third-party software), but that any system could
>>> also be used to compare versions ?
>> The purpose of defining the 'Requires-Dist' field in PEP 345 is to allow
>> for a standardized way of spelling dependences.  If we don't standardize
>> on the versioning, then we won't have gained any ground:  we might as
>> well punt and keep using setuptools, and *forbid* putting versions into
>> 'Requires-Dist' at all.
> 
> The purpose of 'Requires-Dist' is to allow spelling dependencies so that
> a package manager can use these declaration to work. Distutils is not
> that package
> manager. I don't see what is wrong in not forcing a version comparison
> function, but just specifying the "dist_name [<|>|==|!=|>=|<=] version" field
> where the "version" part sorting order is decided by a package manager.

If we allow versions in that field without defining their semantics, and
therefore constraining the available spellings, *nobody* can write tools
which use them, except perhaps for managing only the packages which the
author himself writes.

>>> So we can move on and propose the PEP 345 change unindependantly from
>>> a version comparison tool.
>> I don't understand why we can't just settle on the reduced set:  the
>> exotic cases aren't supported today (in distutils), and are mappable
>> onto the verlib case with some effort.
>>
> 
> To allow a developer that has created his own package manager on the
> top of Distutils, to work with
> his own way with versions numbers, without being forced by Distutils
> to follow any particular
> version scheme if he wants to use 'Requires-Dist'.
> 
> If we force the rule at distutils level, that means we are are saying
> that distutils *is* a package manager .

Not at all:  we are trying to make it possible to develop interoperable
packaging tools, which was the whole point of adding those fields to
PKG-INFO in the first place,  If *package authors* stick to the minimal
rules, and don't depend on / provide anything which can't be spelled
with standard rules, then *any* packaging tool which understands those
rules can manage their packages.

This was the point of PEPs 345 and 386:  Debian maintainers, RPM
packagers, people writing custom tools, all need a regular, uniform,
unambiguous scheme for representing versions.  I am arguing that the
overwhelming majority of released packages do fit into such constraints:
 dumping the constraints for the "benefit" of the tiny handful of
exceptions removes any motivation for having version info in those
fields at all.

Interoperable tools would just drop non-coforming versionson the floor,
with a warning, making the field equivalent to an unversioned distribution.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKUjn9+gerLs4ltQ4RAvRPAJ9BvsI5Em0l0D41mVKKyKXf1+w9VQCgvy5z
t1HC1rU5ANlIG5pwnNRA1WU=
=jmNE
-----END PGP SIGNATURE-----