Re: [Distutils] setuptools extras_require
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?
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
Or use a magic extra name like "default" which is used if no other extra is selected. 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
-- cheers elvelind grandin
On 12/12/06, Elvelind Grandin <elvelind@gmail.com> wrote:
Or use a magic extra name like "default" which is used if no other extra is selected. umm if we make that a list then it could work, it could even be used to get template engines.
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
-- cheers elvelind grandin _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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
On Dec 12, 2006, at 10:32 AM, Elvelind Grandin wrote:
Or use a magic extra name like "default" which is used if no other extra is selected.
+1 on default as a list. TurboGears has its own setup program (based on ez_setup.py) for installing/upgrading setuptools and then installing the "right" TurboGears (where right could mean a version in testing with different dependencies and whatnot). By having a default set of extras, then "easy_install TurboGears" can still work for those that are savvy to easy_install. Kevin
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. I'm not sure if extras is the correct way to do this, since the current TG setup is I want sqlobject OR sqlalchemy, extras is more
On 12/10/06, Phillip J. Eby <pje@telecommunity.com> wrote: like addons. maybe it will need a bigger structure to handle it.
Not currently, no. Do you have any suggestions as to how this might be spelled in the requirements API?
I like the way gentoo handles it on portage. there is this thing call "use flags" which are just a label everyone agrees on it's meaning. so the tg package will have something like IUSE="sqlobject sqlalchemy" so in setup() under install_requires it will do a check like sqlobject? ("SQLObject >= 0.7.1,<=0.7.99") sqlalchemy? ("SQLAlchemy >= 0.3") then (and setuptools doesn't has this) on the pre_install() function you will have something like. if not sqlalchemy in params: set sqlobject as default. and of course sqlobject or sqlalchemy needs to be pass in to determine what you need. now portage is a bigger system since it's supposed to handle compilation of any languaje and USE flags where an abstraction to c/makefile variables to provide the --with,--with-out,etc. I'm not sure if this is a feature python/setuptools needs right now but in the future we'll see many more packages depending on optional backends. or interchangable components. just my 2cents
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
participants (5)
-
Elvelind Grandin -
Jorge Vargas -
Kevin Dangoor -
Matt Good -
Phillip J. Eby