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

"Martin v. Löwis" martin at v.loewis.de
Wed Dec 23 19:07:12 CET 2009

> 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"

I think you are mixing the distutils implementation (and parameters
to the setup function) with PEP 345. This PEP *only* describes a
data format. As such, it is not capable of raising exceptions.

Whether you deprecate parameters to the setup function is an entirely
different issue. Alternatives are removing them entirely, ignoring them,
deprecating them, and conditionally accepting them (on the condition
that they don't get mixed with parameters that are meant for 1.2
of the metadata).

> PEP 314 (PEP 345 predecessor) was implemented in a very particular manner:

PEP 314 was implemented multiple times - not only in distutils, but also
in PyPI (for example).

> 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.

Please do keep distutils out of PEP 345. The remaining occurrences
(such as what the "interpret_marker" function does) should be removed.

> 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.

That is all well, and should probably be extended into the
implementation of PEP 345 in distutils. However, what specifically
distutils does is really not the subject here.

> 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.

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


More information about the Python-Dev mailing list