On Friday 02 November 2007, Christian Theune wrote:
> I see that there is a special 'tests_require' in setuptools anyway.  We
> could give up on extras using tests_require if the testrunner recipe (or
> buildout) knew how to handle those.

Yes, I think this would be the way to go. I have seen this option too, but was 
not sure how supported and desired it is. Jim, can you comment on 
the 'test_require' option?

> I (and other gocept guys) unscrewed the dependencies for almost all
> zope.* packages (at least those that come from the old big tree) using
> this approach. We really wanted to get the normal dependencies right
> there, and moving the test dependencies out of the way was a large part
> of that.

Yes, and it works very well, thanks!

> I'm happy using extras to do that. I'm not 100% sure on the complete
> reasoning against extras but my understanding is that this specific use
> case works. Can someone explain whether this use case has a problem too?

I only know of the general problem and not the specific one. Let's say you 
have a package A with extras AE1 and AE2. Then you really have to write tests 
for three installation cases: A, A with AE1, A with AE2. Currently we do not 
have technology doing this. It gets even worse when you bring another package 
into play. Let's say you have package B with extras BE1 and BE2 that depends 
on package A. You now have to test (B, A), (B, A with AE1), (B, A with AE2), 
(B with BE1, A), ... So the test scenarios multiply. It is just unmanageable. 
To put the final nail in the coffin, extras are not even fully supported by 

Overall I am in favor in switching to 'test_require'.

Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to