[Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Coghlan wrote:
> Tarek Ziadé wrote:
>> Hi,
>>
>> 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          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksxgOgACgkQ+gerLs4ltQ5VdgCgqAFmJ89DbKLw/5YFsasuU6tp
HUYAoK+ek+86Xsq3oVYspEk95OkFaJjv
=nWJT
-----END PGP SIGNATURE-----