[Distutils] RFC PEP 386 : Version comparisons

[Tarek Ziadé]

On Fri, Jul 3, 2009 at 10:25 PM, Floris
Bruynooghe<floris.bruynooghe at gmail.com> 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.