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
forth :P)
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
picked then?
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:
install_requires: Django
And this is a disaster:
Requires: django
Requires: django.conf
Requires: django.contrib
Requires: django.contrib.admin
Requires: django.contrib.admindocs
Requires: django.contrib.auth
Requires: django.contrib.comments
Requires: django.contrib.contenttypes
Requires: django.contrib.csrf
Requires: django.contrib.databrowse
Requires: django.contrib.flatpages
Requires: django.contrib.formtools
Requires: django.contrib.gis
Requires: django.contrib.humanize
Requires: django.contrib.localflavor
Requires: django.contrib.markup
Requires: django.contrib.redirects
Requires: django.contrib.sessions
Requires: django.contrib.sitemaps
Requires: django.contrib.sites
Requires: django.contrib.syndication
Requires: django.contrib.webdesign
Requires: django.core
Requires: django.db
Requires: django.dispatch
Requires: django.forms
Requires: django.http
Requires: django.middleware
Requires: django.shortcuts
Requires: django.template
Requires: django.templatetags
Requires: django.test
Requires: django.utils
Requires: django.views
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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4