Gary Poster wrote:
> On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote:
>> Hi there,
>> I know opinions are divergent about 'extra' dependencies in
>> 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/, 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.
> I do wonder if there's a `` test`` spelling for testing these  
> extras though.  If there were not, I'd find that a good argument  
> against the "extras" pattern, at least for core Zope packages.

It seems there is a 'tests_require'
If your project's tests need one or more additional packages besides 
those needed to install it, you can use this option to specify them. It 
should be a string or list of strings specifying what other 
distributions need to be present for the package's tests to run. When 
you run the test command, setuptools will attempt to obtain these (even 
going so far as to download them using EasyInstall). Note that these 
required projects will not be installed on the system where the tests 
are run, but only downloaded to the project's setup directory if they're 
not already installed locally.

I've seen this used at least here:


Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to