[Python-Dev] My summit notes (packaging)

P.J. Eby pje at telecommunity.com
Sat Mar 28 02:25:29 CET 2009

At 03:06 PM 3/27/2009 -0500, Tarek Ziadé wrote:
>  They both aim at the
>   same goal besides a few differences, and they both rely
>   on a new metadata introduced by setuptools, wich is.
>   "install_requires". This new metadata extends the metadata.
>   described in PEP 314 but is slightly different from.
>   what is descibred in the Draft PEP 345  ("Requires").
>   PEP 345 introduces "Requires" and "Provides" wich are
>   are implemented in Distutils and PyP, but are not
>   widely used. 40 out of +4000 if I remember correctly. Martin will
>   correct me here if I am wrong.

FYI, The reason setuptools uses a different way of specifying 
requirements is that the PEP-proposed way could not be used without 
some kind of indexed repository of packages -- and PyPI did not index 
"provides" at the time.  Also, the PEP-proposed versioning scheme was 
not compatible with the versioning schemes actually used in the field 
at the time.

These conditions could be considered to have changed now, or be 
changeable given enough will and volunteer effort.  Since setuptools 
was only a 1.5-person effort back in the day (i.e., me plus 
occasional contribs from Ian Bicking, Bob Ippolito, and Jim Fulton), 
and backward compatibility was a critical requirement to get 
adoption, using RPM-style provides/requires was not an option at that time.

>     - there should be an API to get metadata for a package without
>     actually executing any of the package's installation script.

Please note that where dependencies are concerned, practical 
considerations require that, at least for currently-released versions 
of Python, a package's dependencies may well be Python-version 
specific.  A library that targets Python 2.4 and 2.5 and uses 
wsgiref, sqlite, ctypes, or ElementTree, for example, may have 
different dependencies depending on the version it is being installed in.

Of course, if future Python versions declare metadata for what they 
include, this could be resolved.  But for existing versions it's a 
bit of a sticky issue.

Also, it's quite likely that platform-specific dependencies may exist 
as well.  It might be possible to accommodate these things with a 
sufficiently flexible format, but currently, the only way to handle 
them with distutils/setuptools is in the setup script.

More information about the Python-Dev mailing list