Hi, Am Freitag, den 02.11.2007, 10:53 -0400 schrieb Stephan Richter:
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.
I do understand the `test extra` is a deviation from `test what you fly, fly what you test`. Which means that the `anti-extras` argument would require us to provide one package with the `pure tests` and put integration tests into another package, carefully selecting which combinations we want that demonstrate support for interoperability.
Overall I am in favor in switching to 'test_require'.
Me too, although I see the point as stated above which is a counter argument. I'm somewhat indecisive right now, but I think that using test_require is better for the current situation than staying with the bad dependency mixture. Maybe some `test-only` integration packages would be nice, but I don't see anybody do the work. Christian -- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development