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

Nick Coghlan ncoghlan at gmail.com
Tue Dec 22 02:17:10 CET 2009

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.

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?)

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?

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.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list