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"],
}
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> > > >
> > >
> > >
> >
> >
>
>
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
