2009/3/5 Gary Poster <gary.pos...@gmail.com>:
> On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote:
>> Hi there,
>> I know opinions are divergent about 'extra' dependencies in setup.py.
>> These ar dependencies that effectively make a single project with a
>> single dependency structure into a number of "virtual" packages that
>> each can have a separate list of dependencies. Such a virtual package
>> that we're currently getting rid of is zope.component[zcml].
> I disagree with the blanket statement.
> I do lean towards not having the extras for the test package only.
> I'm fine with the policy "If you want zope.testing for your tests,
> then keep it as a dependency for the package".
> But I like to have the option of extras for testing additional setups.
> zc.async uses extras so that the main tests show the functionality as
> a Python library; another level adds more Zope dependencies, with
> associated tests; and the last level adds the most. I could have
> divided these up into multiple teensy-weensy packages but I didn't
> really want to. It seemed like overkill.
> I've also done this in other circumstances in which code could use
> zope.proxy/zope.security, but I really didn't want to add the hard
> dependency. The tests to show that proxies were handled correctly
> were only part of the "extras". Dividing this package also would have
> made no sense--it was already just a few small classes.
> For a package as central as zope.component, I think the pattern Tres
> is pursuing--dividing everything up--makes sense.
> For most other packages, I personally feel that there are
> circumstances in which extras are a useful tool.
A strong +1 on that explanation.
WBR, Dan Korostelev
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -