Re: [Distutils] setuptools extras_require
On Thu, 2006-12-14 at 07:15 +0100, Elvelind Grandin wrote:
Perhaps I wasn't totally clear. what I meant was something like this.
extras_require = { "default" : ["SQLObject==bugfix,>=0.7.1dev-r1860,<=0.7.99"], "future" : ["Genshi>=0.3", "SQLAlchemy>=0.3"] },
From a semantic perspective I think listing these as "extras" is odd. One of either SQLObject or SQLAlchemy is required for installation, so it's not just an "extra" feature. I think extras have been used for
That may be ok for the example, but what happens if you add another extra "foo" for some optional feature. Installing "TurboGears[foo]" won't select either the "default" or "future" extras, so you don't really get all the requirements. this as a workaround to setuptools not supporting ORed requirements, but I'd like to see that fixed. I tend to think in terms of Debian packages where stuff like SA or SO would be listed as "depends" meaning that they're strictly required, so in setuptools this would correspond to "install_requires". On the other hand I believe Paste is still an optional package used in TurboGears for stuff like the interactive traceback display, so it'd be a Debian "recommends", or setuptools "extras". Using "|" as a separator for ORing TurboGear's requirements might look something like this (ignoring version numbers for simplicity): install_requires = [ "SQLObject | SQLAlchemy", "Kid | Genshi", ], extras_require = { "fancy_tb": ["Paste"], } Setuptools would check if either SQLObject or SQLAlchemy was already installed, if not it'd try from left to right until it successfully installed one of the requirements. I suppose extras could still be used as aliases for something like the "future" requirements to make it easier for users to install this set of packages: extras_require = { "standard": ["Kid", "SQLObject"], "future": ["Genshi", "SQLAlchemy"], "fancy_tb": ["Paste"], } Alternatively tuples could be substituted to define ORed requirements like: install_requires = [ ("SQLObject", "SQLAlchemy"), ("Kid", "Genshi"), ] Comments? -- Matt Good
On 12/12/06, Matt Good <matt@matt-good.net> wrote:
On Tue, 2006-12-12 at 16:32 +0100, Elvelind Grandin wrote:
Or use a magic extra name like "default" which is used if no other extra is selected.
This doesn't really address the full issue, since there may be several sets of alternative dependencies for different requirements.
Following the TurboGears example it needs an ORM from "SQLObject or SQLAlchemy" and a template engine from "Kid or Genshi". So it'd need defaults for each, not just a single default.
On 12/11/06, Elvelind Grandin <elvelind@gmail.com> wrote:
Not really
extras_require = { 'PDF': ["ReportLab>=1.2", "RXP"], } extras_exclude = { 'PDF': ["Foo"], }
might work. even if it's not that pretty.
On 12/10/06, Phillip J. Eby <pje@telecommunity.com> wrote:
At 08:28 PM 12/10/2006 +0100, Elvelind Grandin wrote:
Is there any way to exclude packages in extras_require as opposed to just include them. In Turbogears we have Sqlobject in by default. but if the extra "future" is used it should drop SO and install sqlalchemy instead.
Not currently, no. Do you have any suggestions as to how this might be spelled in the requirements API?
-- cheers elvelind grandin
Hi. I'd like to produce an egg by compiling swig code for a particular platform. Can someone advise a blueprint for this. Many thanks. Regards, David
At 05:49 PM 12/14/2006 -0400, David Pratt wrote:
Hi. I'd like to produce an egg by compiling swig code for a particular platform. Can someone advise a blueprint for this. Many thanks.
See http://python.org/doc/2.4.1/dist/dist.html and http://python.org/doc/2.4.1/dist/describing-extensions.html especially section 2.3.2, which notes that you can use .i files as Extension() sources. Add the necessary information to your setup.py and run bdist_egg on the appropriate platform(s) to create the egg(s) you want.
Many thanks for this Phillip. I'll give this a try. Regards, David Phillip J. Eby wrote:
At 05:49 PM 12/14/2006 -0400, David Pratt wrote:
Hi. I'd like to produce an egg by compiling swig code for a particular platform. Can someone advise a blueprint for this. Many thanks.
See http://python.org/doc/2.4.1/dist/dist.html and http://python.org/doc/2.4.1/dist/describing-extensions.html
especially section 2.3.2, which notes that you can use .i files as Extension() sources. Add the necessary information to your setup.py and run bdist_egg on the appropriate platform(s) to create the egg(s) you want.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Good wrote:
On Thu, 2006-12-14 at 07:15 +0100, Elvelind Grandin wrote:
Perhaps I wasn't totally clear. what I meant was something like this.
extras_require = { "default" : ["SQLObject==bugfix,>=0.7.1dev-r1860,<=0.7.99"], "future" : ["Genshi>=0.3", "SQLAlchemy>=0.3"] },
That may be ok for the example, but what happens if you add another extra "foo" for some optional feature. Installing "TurboGears[foo]" won't select either the "default" or "future" extras, so you don't really get all the requirements.
From a semantic perspective I think listing these as "extras" is odd. One of either SQLObject or SQLAlchemy is required for installation, so it's not just an "extra" feature. I think extras have been used for this as a workaround to setuptools not supporting ORed requirements, but I'd like to see that fixed. I tend to think in terms of Debian packages where stuff like SA or SO would be listed as "depends" meaning that they're strictly required, so in setuptools this would correspond to "install_requires". On the other hand I believe Paste is still an optional package used in TurboGears for stuff like the interactive traceback display, so it'd be a Debian "recommends", or setuptools "extras".
Using "|" as a separator for ORing TurboGear's requirements might look something like this (ignoring version numbers for simplicity):
install_requires = [ "SQLObject | SQLAlchemy", "Kid | Genshi", ], extras_require = { "fancy_tb": ["Paste"], }
+1 for the pipe symbol: to my eye, it means "pick the first of these", which is what you want.
Setuptools would check if either SQLObject or SQLAlchemy was already installed, if not it'd try from left to right until it successfully installed one of the requirements.
I suppose extras could still be used as aliases for something like the "future" requirements to make it easier for users to install this set of packages:
extras_require = { "standard": ["Kid", "SQLObject"], "future": ["Genshi", "SQLAlchemy"], "fancy_tb": ["Paste"], }
Alternatively tuples could be substituted to define ORed requirements like:
install_requires = [ ("SQLObject", "SQLAlchemy"), ("Kid", "Genshi"), ]
Comments?
I have a need for the "alternate dependencies" myself, e.g.: install_requires = ['lxml | elementtree'] where my package prefers lxml, but can fall back to using elementtree. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFzIU/+gerLs4ltQ4RAseRAJ4xhRcRmJbPegE1+ExInh9/VlZ4cgCbBhHO WlAJp1wRhxvnWQgoJ/T61oU= =yDKv -----END PGP SIGNATURE-----
At 09:29 AM 2/9/2007 -0500, Tres Seaver wrote:
Using "|" as a separator for ORing TurboGear's requirements might look something like this (ignoring version numbers for simplicity):
install_requires = [ "SQLObject | SQLAlchemy", "Kid | Genshi", ], extras_require = { "fancy_tb": ["Paste"], }
+1 for the pipe symbol: to my eye, it means "pick the first of these", which is what you want.
It's also implementable; the tuple concept isn't. Eggs' requirements get stored in text files, so there has to be a pure-text representation possible.
Setuptools would check if either SQLObject or SQLAlchemy was already installed, if not it'd try from left to right until it successfully installed one of the requirements.
Yeah, it would be pretty straightforward to add the parsing and a new type of "Requirement" object to support alternatives, *but* nearly all of setuptools expects individual Requirement instances to refer to a single project, not multiple alternative projects. Integrating an alternative type of "MultiRequirement" object could introduce random breakage. Essentially, everything that uses Requirement.parse would need to be changed to handle the case where alternative requirements were included, and for some parts of setuptools it would be a significant change. So, this is something that'll have to wait for 0.7. Also, there are some open design questions with this idea. For example, will we need command-line options to allow someone to force installing the "best" choices, even if a less-desirable option is still available? (I suppose this could be handled with an extra, e.g. "foo[recommended]".) And what kinds of installation problems should be considered "recoverable"? Do we want to install a lesser alternative just because a server is down at the moment? Should we in fact ever try to *install* an alternative, or merely allow already-installed alternatives to satisfy a dependency? Yet another problem is backtracking. Right now, the dependency resolving algorithm never backtracks. But in the world of allowing alternatives, it seems as though it would need to be able to back out if the first thing is installed, but one of *its* dependencies is missing. Although I suppose that could just produce an error... but right now there's no easy_uninstall to let you remove the broken item easily. (These types of questions are why I never implemented this in the first place.)
On 2/9/07, Phillip J. Eby <pje@telecommunity.com> wrote:
At 09:29 AM 2/9/2007 -0500, Tres Seaver wrote:
Using "|" as a separator for ORing TurboGear's requirements might look something like this (ignoring version numbers for simplicity):
install_requires = [ "SQLObject | SQLAlchemy", "Kid | Genshi", ], extras_require = { "fancy_tb": ["Paste"], }
+1 for the pipe symbol: to my eye, it means "pick the first of these", which is what you want.
It's also implementable; the tuple concept isn't. Eggs' requirements get stored in text files, so there has to be a pure-text representation possible.
[blast from the past] I'd like to use ORed requirements in a setup file but I don't see what version of setuptools this was introduced in. Does anyone know? I was looking at: http://peak.telecommunity.com/DevCenter/EasyInstall#release-notes-change-his... thanks, Kumar
participants (5)
-
David Pratt -
Kumar McMillan -
Matt Good -
Phillip J. Eby -
Tres Seaver