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

Tarek Ziadé ziade.tarek at gmail.com
Thu Dec 24 10:45:12 CET 2009


2009/12/23 "Martin v. Löwis" <martin at v.loewis.de>:
>> So that will happen in the code of course, but we need the PEP to state clearly
>> wether metadata 1.0 and 1.1 should be dropped by implementations or not.
>
> Ok. We should recommend that implementations support these versions
> indefinitely. I see no point in dropping them.
>
> But then, this is really up to the implementations.

OK, that's fine with me. So I'll remove references to deprecated
fields in PEP 345, which will
just describes 1.2, and I will also remove the fact that it was marked
as the replacer of PEP 314 in
the header.

[..]
>> PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ?
>
> Correct - but that's also an implementation of the PEP.
>
>> I am referring to the implementation in Distutils that produces 1.0
>> *or* 1.1 PKG-INFO files.
>
> But it works both ways. Applications that consume then need to decide
> what versions they want to consume.

They know it because it is marked in the file in the first line. e.g.
a reader has
to be able to read all versions. IOW they are not the ones that decide what
metadata version a distribution contains.


>>> Please do keep distutils out of PEP 345. The remaining occurrences
>>> (such as what the "interpret_marker" function does) should be removed.
>>
>> That's the reference implementation of a PEP 345 reader/writer that
>> happens to be in the stdlin. For what reason should we remove it from
>> the PEP ?
>
> Because there shouldn't be a reference implementation. If we have
> both a spec and an a reference implementation, then we need to define
> what happens in case they conflict. If the reference implementation
> is right, implementers of the PEP would *also* need to study the
> reference implementation to find out what conforming behaviour is.
>
> This is bad; the PEP should be the only definition of the metadata
> format.

Ok, I'll remove that part.


Regards
Tarek
-- 
Tarek Ziadé | http://ziade.org


More information about the Python-Dev mailing list