[Distutils] Finishing PEP 345

[Tarek Ziadé]

On Tue, Dec 22, 2009 at 2:13 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> FYI. This Distutils-SIG thread is about proposing PEP 345 and impacts PyPI.
>> So if there's anything that look suspicious to anyone, please join the
>> discussion at Distutils-SIG
>
> In a number of places (Requires-Dist, Requires-Python), comma-separated
> lists of version constraints are used. The PEP needs to specify what the
> collective constraint means that gets specified.
>
> Most likely, the intended meaning is that the constraints get
> and-combined, in which case the example
>
> Requires-Python: 2.5, 2.6
>
> is non-sensical (no Python release meets that constraint). (else,
> if it was meant to denote or-combination, then ">1.0, !=1.3.4, <2.0"
> would be non-sensical, specifying no constrating at all)

Right, this is not good because the comma means "and" then "or"

I see two ways to fix this:

- introduce groups, and say the the comma is "or" inside a group:

    0.9, (>1.0, !=1.3.4, <2.0), 3.4   ==> 0.9 or (>1.0 and !=1.3.4 and
<2.0) or 3.4

- use an explicit separator word (and/or)

>
> For the Copyright field, I'm not sure what the purpose of it is.
> If it is what I think it is (listing attribution), it should probably
> be specified as "multiple use".

I just noticed this field was added after PEP 314. I don't think we
should keep it at all.
I don't see a use case for this (README etc.. are enough for copyright matters)

>
> For Documentation, I think the entire field must be reconsidered.
> If it is really meant to be reStructuredText, then the spec should
> explain how to do leading spaces/indentation.

Yes, this is the case in fact. but the way it currently works is
deficient because
you may lose empty lines because the PKG-INFO file works.

What I have suggested last week was to introduce a delimiter to start
each new line so
this field stays RFC 822 compatible and reST works if we want to read
back the value:

Description: This module collects votes from beagles
           | in order to determine their electoral wishes.
           | Do *not* try to use this module with basset hounds;
           | it makes them grumpy.
           |
           | example code :
           |
           |      >>> 2 + 1
           |      3


A cleaner option of course, is to drop the RFC 822 format and to use a
simpler format like json for example, since we have a reader/writer
for that in the stdlib. But that
a big change...

>
> For Platform, I fail to see the point of supporting both multiple
> use, and comma-separated lists.

Right. This is PEP 314 though, so we will need a deprecation cycle.
The simplest way to fix this is to use (multiple use) and deprecate
comma-separated I guess.

>
> For Metadata-Version, I think formally, the only legal value according
> to the PEP is 1.2. If 1.0 and 1.1 are also conforming values, the PEP
> should elaborate what it means to put a different version number into
> the field.

Right. I'll extend on this

Thanks for all this feedback
Tarek