On Fri, Jul 3, 2009 at 10:25 PM, Floris Bruynooghe<[email protected]> wrote: > On Fri, Jul 03, 2009 at 02:20:51PM +0200, 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] > > But does this not mean that you can end up with different results then > intended? E.g. the developer uses pip but the user installs with > easy_install and because version comparison is not standardised the > user could end up with a version not intended by the developer. > > Or did I miss an essential part of the discussion? >
Exactly so, because the version comparison is provided by the package manager that checks what's installed, what should be upgraded, etc. not by a package alone or by distutils. That is pip, or easy_install, or any tool that actually compares versions. They are the one that can define the rule. So, as a developer, if your version scheme doesn't sort well when used in one of the package manager out there, you are screwed. And even if you are not screwed at Python level, and if your package make it to an os packager, you might get screwed then. But it's OK as long as you stick with one package manager philosophy and you adapt your version scheme when packagers ask you to do so. For instances some developers don't release but debian packages and don't care about the problems we are trying to fix here. Other are safe because they rely on setuptools scheme (wheter they us pip or easy_install) in PythonLand. And as soon as their distributions are turned into a deb/rpm, they fix their version schemes if there's a problem. In other words, we are currently anoying all the python developers out there that don't have a developement cycle that generate dev. versions, or a lot of alphas, betas. They don't understand why Python should force a complex version scheme to version their packages when they have very simple schemes like 1.0/1.1 etc.. which are fine. If the whole Python community would find a consensus on a version comparison scheme *including* developement versions, we could have an unified tool. But that's not the case and people will always "dislike" the way we set the rule . So unless Guido says : "this is how we compare versions in Python", this unification won't happen I believe. And I don't think he'll ever say it because enforcing such a rule doesn't sound right to me from a pythonic point of view. If distutils was a package manager I'd force a rule. I'd try to be a dictator for PEP 386. But it's not so it's hard to do so legitimately. > It was my impression that one, or even a few, incarnations of the > verlib.py where pretty close to something that most people could live > with. *pretty* close, but you will still get rants. That's what I've been experiencing since the last Pycon. PEP 345 is waiting for that versionning stuff, and I'd like to see it moving forward. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
