[Zope-dev] setup.py "extra" dependencies

[Dan Korostelev]

2009/3/5 Gary Poster <gary.poster at 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].
>
> ...
>
>> Opinions?
>
> 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