[Python-Dev] My summit notes (packaging)
kevin at bud.ca
Sat Mar 28 03:54:40 CET 2009
On Mar 27, 2009, at 6:25 PM, P.J. Eby wrote:
> 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.
Tarek, was there any further discussion on "Requires" vs
"install_requires" or any decisions made on what to do about this?
(I've got a +1 ready for including 'install_requires' in the standard
package metadata and marking 'Requires' as deprecated if that was put
From what I understand of PEP 345's "Requires" and "Provides" fields
is that it's not possible to use them unambigously? For example, if
I'm working on a Python project and want to depend upon a project that
provides a 'utils' module, there could be several packages on PyPI
that declare they provide a 'utils' module. Which project would get
It's also a lot more succinct to just spell out the project name in
the "install_requires" field than to have to list all of the modules
and packages you expect to use in the project you are depending upon.
For example, this is pretty reasonable:
And this is a disaster:
Not to mention that if you were upgrading to a newer version of Django
you'd could no longer just say '1.0' or '1.1' in 'install_requires'
but would instead have to fiddle with the Requires list to match newly
introduced modules and packages. I guess one is supposed to just list
"Requires: django" since that would resolve to the Django project
which, and it's implied that it would then provide everything else? Or
perhaps one is supposed to comb through their code and just list the
particular bits of Django that they're importing and using? There are
other times when a project may provide several top-level packages, and
again it's a lot easier to just ask for the project name rather than
list all of the top-level packages (usually this type of project is
kept on an private package server where it's reasonable to occupy
common top-level names such as 'utils' without worrying too much about
naming conflicts). Additionally, consuming the "Requires" field is
always more work, since you need to do some kind of look-up to go from
module/package name to project name before you can fetch a
distribution for that project.
More information about the Python-Dev