[Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2 (original) (raw)

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 "interpretmarker" 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