[Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

Tarek Ziadé ziade.tarek at gmail.com
Mon Dec 28 01:37:09 CET 2009

On Mon, Dec 28, 2009 at 1:15 AM,  <david.lyon at preisshare.net> wrote:
>> On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> Martin v. Löwis wrote:
>> FYI we have introduced a range operator, so one may define a range of
>> versions.
>> This is useful for instance to write:
>>   Requires-Python: ~=2.5
>> Which means: requires any version of Python 2.5.x. This operator is
>> the default operator,
>> meaning that you can also write:
>>   Requires-Python: 2.5
> I don't like the ~ at all sorry. The ~ operator is thoroughly confusing.
> No application developer will quickly figure out what a tilde means. Maybe
> it means 'roughly', but it requires too much thought and is ambiguous. 2.5
> is not roughly 2.5.2. It is the same exactly.

As discussed in Distutils-SIG, 2.5 is not strictly equal to 2.5.2.
That's exactly why we introduced
the range operator. So one may make a clear distinction between
"2.5.x" and "2.5".

Developers will be able to omit the ~= operator, so they can describe
a MAJOR or
MAJOR.MINOR version and have the whole range included.

> Before we had : Requires-Python: 2.5, 2.6
> That made much more sense. It was simple and unambiguous, and is relevant
> to typical packaging scenarios.

This was ambiguous because it was unclear, as MvL stated,  if "2.5"
was just "2.5.0" or included
versions like "2.5.1" or "2.5.2". The "==" operator is now a strict
equal operator.

In the current proposal, "Requires-Python: 2.5, 2.6"  is equivalent to
"Requires-Python: ~=2.5, ~=2.6",
which means "Requires Python 2.5.x or Python 2.6.x".

So I guess the meaning you were putting behind "Requires-Python: 2.5,
2.6" remains unchanged.

> I hope we can go back to the original proposal.

This new operator removes the ambiguity the original proposal had,
without making it more
complex for common use cases. So if you dislike it, you will need to
propose something
else that also fixes the ambiguity we had.


More information about the Python-Dev mailing list