As an application developer, I really stand with Tarek here.
Not sure what specific point of Tarek you are supporting, though.
I think we want something stronger than that since they were not really used by the community and removed and replaced by something better. Using them should raise a warning so developers abandon them, so it would be "don't use 1.1 anymore"
Yes. But that is a software warning message to be implemented within the installation software. The important thing is what is in the metadata.
That's my point, not Tarek's, though (the text you quote and that you seem to object to is from Tarek).
I am just describing the needs and the end user PoV with the reference implementation that happens to be used by *all* tools out there.
That's good. That's what we need right now.
Why then bother with describing the data format, when you *really* want people to use the API? Shouldn't you then define the API instead, and leave the format as an implementation detail?
I'm fine with having a sample implementation that tools *may* use, but it should be possible to implement the PEP without the sample implementation (and indeed, PyPI may not use that sample implementation, as it has already implemented most of the PEP, to support earlier versions).
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.
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.
That's a software implementation issue. Not a metadata issue.
Above you say that the PEP should specify whether to keep or drop 1.0 and 1.1, and now you say that whether dropping 1.0 is not a metadata issue (and, presumably, out of scope of the PEP)???