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 setuptools. Overall I am in favor in switching to 'test_require'. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training