[Distutils] PEP 345 update + RFC on "Requires-External" and "Requires-Python"

M.-A. Lemburg mal at egenix.com
Mon Nov 16 11:55:44 CET 2009

Tarek Ziadé wrote:
> Hello
> I've update PEP 345 with a first draft about the markers,
> http://python.org/dev/peps/pep-0345/#environment-markers

Thanks for adding this.

One detail to add:

python_full_version = sys.version.split()[0]

This is important, since a package may well only support Python
2.5 starting with patch level release 2.5.2 and python_version
only includes the major.minor version information.

> PEP 390 is being reworked accordingly, but I guess we can have a new round of
> comments on PEP 345 and PEP 386, as they can be accepted and added in Python
> independently from the other PEPs.
> There's also a "Requires-External" field that was added in the first
> update of 345, that we need to discuss.
> The idea of this field is to be able to define a non-Python dependency
> in the metadata. It's based on a list stored and managed at PyPI.
> Values could be things like "libxslt", "libpng", etc..

Am I right in understanding this as informational field only ?

Different systems have different ways of naming such external
dependencies, so it's unlikely that we can come up with our own
little standard set of names for everything, e.g. you could
use any of these names for a dependency on zlib and its header
files: "zlib", "libz", "zlib-devel", "zlib-dev".

It is also not clear where to draw the line and how to manage
multiple mentions with slightly different focus, e.g. would you have
both "zlib" and "zlib-devel" (extensions may require the binary
and/or the lib and header files), or would "zlib" include the header
files dependency ?

Given the complexity this adds, I'm not sure whether it's worth
trying to come up with a fixed list of names for external

> Last, "Requires-Python" is introduced to define the version of Python.
> I am not sure this is required anymore since Martin has added a Trove
> classifier
> for this. But in the meantime, this is stronger than a "simple"
> classifier I think.

This may be useful for cases like the one mentioned above (patch
level requirements), which are not covered by the trove classifiers.

Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, Nov 16 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

More information about the Distutils-SIG mailing list