-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote: > On Sun, Jul 5, 2009 at 6:26 PM, Tres Seaver<[email protected]> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Tarek Ziadé wrote: >>> On Sat, Jul 4, 2009 at 8:12 PM, Tres Seaver<[email protected]> 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 [email protected] 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----- _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
