-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nick Coghlan wrote:
Tarek Ziadé wrote:
On behalf of the Distutils-SIG, I would like to propose to addition of PEP 345 (once and *if* PEP 386 is accepted).
+1 for integrating all the good work the catalog-sig folks have been doing.
Some comments on PEP 345 specifically though:
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.
Good point. I thought I had done so in the initial editing pass.
There also needs to be an explanation in the PEP as to whether or not it is legal to use both Requires and Requires-Dist (etc) in the same PKG-INFO file. (i.e. what is the use case for allowing the old fields to be used in a metadata v1.2 PKG-INFO file? Should PEP 345 aware packaging tools just ignore the old fields, while v1.1 tools ignore the new ones? Or should new tools attempt to handle both?)
No tools that I know of currently use 'Requires' / 'Provides' / 'Obsoletes' at all: their contents have never been informative enough to allow for useful automation. For completeness sake, we can document that tools should ignore any 'Requires', 'Provides', or 'Obsoletes' fields when any of the '-Dist' versions are present.
The various lines about there being no standards or canonical definitions for particular fields also seem to run counter to the spirit of the detailed guidelines in the description of each field (which imply that some standards have already been adopted by convention). Perhaps these comments could be softened to say that although the metadata specification formally allows arbitrary strings in these fields, the descriptions are recommended guidelines for creating field entries that automated tools will handle correctly?
That language is left over from PEP 314, which introduced those "advisory" fields. The expectation of PEP 345 is that developers who want their packages to be easily consumable by automated tools will avoid the deprecated fields and use the more usefully-specifiied new ones.
Finally, as a general formatting request - some blank space between the end of the previous example and the header for the next field description would make the field descriptions much easier to read.
Hmm, I thought we were following stock ReST formats: perhaps the CSS should be adjusted to give a larger leading space to headings?
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 firstname.lastname@example.org Palladion Software "Excellence by Design" http://palladion.com