Re: [Checkins] SVN: zope.file/trunk/ Make a good package out of this package.
Stephan Richter wrote:
Log message for revision 81401: Make a good package out of this package.
Changed: A zope.file/trunk/CHANGES.txt A zope.file/trunk/README.txt U zope.file/trunk/buildout.cfg U zope.file/trunk/setup.py
+ extras_require = dict( + test=['zope.app.testing', + 'zope.app.securitypolicy', + 'zope.app.zcmlfiles', + 'zope.testbrowser', + 'zope.formlib', + 'zope.app.server']),
Why the test extra? -- Benji York Senior Software Engineer Zope Corporation
On Friday 02 November 2007, Benji York wrote:
Why the test extra?
to get it working. :-) There were several packages required by ftesting.zcml. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
On Friday 02 November 2007, Benji York wrote:
Why the test extra?
to get it working. :-) There were several packages required by ftesting.zcml.
We generally put those in install_requires and eschew extras. -- Benji York Senior Software Engineer Zope Corporation
On Friday 02 November 2007, Benji York wrote:
Stephan Richter wrote:
On Friday 02 November 2007, Benji York wrote:
Why the test extra?
to get it working. :-) There were several packages required by ftesting.zcml.
We generally put those in install_requires and eschew extras.
zope.file was the *only* package of the 150+ I worked on that did not have extras. If this changes, I want a canconical community decision with someone writing a script fixing it everywhere for the next releases. I know why extras are bad, Jim explained it to me. I would still argue that we need them (for tests only, of course!!!!). For example, the zope.file tests require zope.app.zcmlfiles, which effectively pulls in 70 packages, including the entire ZMI, Rotterdam, and old form framework. But what if I do not want to install ZMI, Rotterdam and the old form stuff and just use the API of zope.file? I think that extras for tests are a necessary evil until we have unscrewed the dependencies of the functional test setups. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Hi, Am Freitag, den 02.11.2007, 10:23 -0400 schrieb Stephan Richter:
On Friday 02 November 2007, Benji York wrote:
Stephan Richter wrote:
On Friday 02 November 2007, Benji York wrote:
Why the test extra?
to get it working. :-) There were several packages required by ftesting.zcml.
We generally put those in install_requires and eschew extras.
zope.file was the *only* package of the 150+ I worked on that did not have extras. If this changes, I want a canconical community decision with someone writing a script fixing it everywhere for the next releases.
Hmm. I've been doing that dance using extras too. 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. 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. 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 know why extras are bad, Jim explained it to me. I would still argue that we need them (for tests only, of course!!!!). For example, the zope.file tests require zope.app.zcmlfiles, which effectively pulls in 70 packages, including the entire ZMI, Rotterdam, and old form framework. But what if I do not want to install ZMI, Rotterdam and the old form stuff and just use the API of zope.file?
I think that extras for tests are a necessary evil until we have unscrewed the dependencies of the functional test setups.
Depends on what 'unscrew' means. Functional test setups might want to demonstrate more in-depth, "real-life" scenarios where they have to introduce more dependencies than the actual package itself needs, so two sets of dependencies are needed anyway, or not? 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
On Friday 02 November 2007, Christian Theune wrote:
I think that extras for tests are a necessary evil until we have unscrewed the dependencies of the functional test setups.
Depends on what 'unscrew' means. Functional test setups might want to demonstrate more in-depth, "real-life" scenarios where they have to introduce more dependencies than the actual package itself needs, so two sets of dependencies are needed anyway, or not?
He he, yep, you are right. The point I was trying to make is that unscrewing the functional tests dependencies is a pointless exercise since you want to demonstrate the functionality in one more realistic environment. Like you said. And those dependencies might not match my use of the package. BTW, I think you guys did a good job of separating the real and testing dependencies for the Zope packages. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
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
Stephan Richter wrote:
Overall I am in favor in switching to 'test_require'.
If I recall correctly, "test_require" doesn't actually do anything. :) -- Benji York Senior Software Engineer Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benji York wrote:
Stephan Richter wrote:
Overall I am in favor in switching to 'test_require'.
If I recall correctly, "test_require" doesn't actually do anything. :)
setuptools installs 'tests_requires' dependencies when you run tests from 'setup.py test'. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHK1iH+gerLs4ltQ4RAkrsAJ9ZgWURsjHOpo0QhiG0uAcE6tGVRwCfeC7d ULER61tzhrSJUJ7ckH0N7v8= =vHrB -----END PGP SIGNATURE-----
On Nov 2, 2007, at 1:04 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Benji York wrote:
Stephan Richter wrote:
Overall I am in favor in switching to 'test_require'.
If I recall correctly, "test_require" doesn't actually do anything. :)
setuptools installs 'tests_requires' dependencies when you run tests from 'setup.py test'.
Benji meant "doesn't actually do anything useful". :) Jim -- Jim Fulton Zope Corporation
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Theune wrote:
Hi,
Am Freitag, den 02.11.2007, 10:23 -0400 schrieb Stephan Richter:
On Friday 02 November 2007, Benji York wrote:
Stephan Richter wrote:
On Friday 02 November 2007, Benji York wrote:
Why the test extra? to get it working. :-) There were several packages required by ftesting.zcml. We generally put those in install_requires and eschew extras. zope.file was the *only* package of the 150+ I worked on that did not have extras. If this changes, I want a canconical community decision with someone writing a script fixing it everywhere for the next releases.
Hmm. I've been doing that dance using extras too.
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.
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.
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 know why extras are bad, Jim explained it to me. I would still argue that we need them (for tests only, of course!!!!). For example, the zope.file tests require zope.app.zcmlfiles, which effectively pulls in 70 packages, including the entire ZMI, Rotterdam, and old form framework. But what if I do not want to install ZMI, Rotterdam and the old form stuff and just use the API of zope.file?
I think that extras for tests are a necessary evil until we have unscrewed the dependencies of the functional test setups.
Depends on what 'unscrew' means. Functional test setups might want to demonstrate more in-depth, "real-life" scenarios where they have to introduce more dependencies than the actual package itself needs, so two sets of dependencies are needed anyway, or not?
Maybe the functional tests could declare their dependencies using teh following idiom (rather than listing them in setup.py): import pkg_resources from setuptools.command.easy_install import main FTEST_REQUIREMENTS = ['foobar=1.2.3', 'bazbam>=3.2'] try: pkg_resources.require(FTEST_REQUIREMENTS) except pkg_resources.DistributionNotFound: main(argv=FTEST_REQUIREMENTS) pkg_resources.require(FTEST_REQUIREMENTS) Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHK1gq+gerLs4ltQ4RAmp7AKC+0CqxsNDIBKHC4bxIOqNXtJ0p8gCfUdrU yhHxOnicWEDsgziA/ISVgU8= =s3OM -----END PGP SIGNATURE-----
Stephan Richter wrote:
zope.file was the *only* package of the 150+ I worked on that did not have extras.
I'm surprised. I thought it was generally agreed upon not to do that. Darn. -- Benji York Senior Software Engineer Zope Corporation
On 02.11.2007, at 15:43, Benji York wrote:
Stephan Richter wrote:
zope.file was the *only* package of the 150+ I worked on that did not have extras.
I'm surprised. I thought it was generally agreed upon not to do that. Darn.
no - afaik there is no agreement upon this, and imho it is not good to put extras in the general deps because one always ends up fetching all the zope packages as deps if using any zope.* package -100 from me for removing extras
-- Benji York Senior Software Engineer Zope Corporation _______________________________________________ Checkins mailing list Checkins@zope.org http://mail.zope.org/mailman/listinfo/checkins
-- Lovely Systems, senior developer phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria skype: bernd.dorn
participants (6)
-
Benji York -
Bernd Dorn -
Christian Theune -
Jim Fulton -
Stephan Richter -
Tres Seaver