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.
PEP 314 (PEP 345 predecessor) was implemented in a very particular manner:
PEP 314 was implemented multiple times - not only in distutils, but also in PyPI (for example).
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.
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.
This will be clearer I think.
It would be also incompatible with existing consumers that expect a Python package to have an earlier version of the metadata. Dropping 1.0 may be fine though - but again, this is out of scope here.
I don't understand why you are saying this is out of scope. Shouldn't we state clearly in the PEP that 1.0 and 1.1 should not be used in the future ?
In terms of conformance, what would that mean? If I implement 1.0 (in addition to also implementing 1.2), would I then be non-conforming (because the PEP says I should not support 1.0)? For PyPI, that would be fairly bad, as it will need to support earlier versions for many years to come (at a minimum, 10 years).