2009/12/23 "Martin v. Löwis"
The deprecation of the existing Requires/Provides/Obsoletes fields should be more prominent - tucked away below the examples, I missed these notices on the first read through (I only noticed that they actually had been formally deprecated when I got to the summary of differences at the end). I suggest placing the deprecation notice immediately after the relevant field headers.
I would go beyond deprecation, and propose to remove them altogether.
In the metadata format, there is no point in deprecating something. If you have a valid use for these fields, use version 1.1.
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" PEP 314 (PEP 345 predecessor) was implemented in a very particular manner: If you do use options like 'requires' in Distutils' setup.py, your package ends up with a PKG-INFO Metadata v1.1. Otherwise it stays v1.0. In other words, v1.0 was not really superseded by v1.1. The latter was just an alternative version and the current Distutils can produce both depending on the options you use in your setup.py. Once 1.2 is defined, we could deprecate the options that are corresponding to 1.1 at Distutils' level and make Distutils only produces metadata v1.2 PKG-INFO files (even if the options used by the developer could be written in a valid 1.0 format). This will be clearer I think. So, I am +1 for removing deprecated fields from PEP 345 and work on the deprecation issues at the code level in Distutils. Meaning Distutils' DistributionMetadata class will provide a way to read 1.0/1.1/1.2 but will only write 1.2 starting at 2.7/3.2, If a deprecated option is used, Distutils will produce a 1.1 with a warning. If a deprecated option is used together with a new option, like Require and Require-Dist, it will raise an error. Regards, Tarek