-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roger Ineichen wrote:

Hi again

...

Betreff: [Zope-dev] Heads up: Dependencies!

Hi all

I try to do a cleaup all zope packages and found some wired dependencies and bad setup. One of this bad things is the following:

The zope.dublincore package defines in setup.py

install_requires = ['setuptools', 'zope.annotation', 'zope.component', 'zope.interface', # testing dependencies 'zope.testing', 'zope.security', 'zope.app.testing', ],

I guess this is one of the packages which makes it impossible to get rid of testing stuff on production servers! right or not?

This happens in 3.4.0, 3.4.0a1 was Ok.

Can anybody agree that the testing dependencies should go to extra_requires ['test'] ?

I discussed this with Benji on IRC and very bad consenus happend. Benji told me that this topic was discussed and this changes explicit happens.

I totaly disagree with the concept behind this. The general sentence "Test what you fly and flay what ou test" is still valid and makes sense to me. But this is not what this changes reflect. This changes will bring in dependencies to zope.app.testing for all our production projects. This is just not true. All of our apps are just working without the testing dependency. Testing code is not a dependency for production servers.

This install_requires will bring in zope.app.testing dependencies for all of our production servers which is just wrong.

Test what you fly and fly what you test is a good thing. But it get totaly miss understud in this usecase.

It doesn't mean that we can depend our tests on zope.app.rotterdam for zope.dublincore just because we have a rotterdam package. And even worse depend on that in install_requires.

If a testing setup needs additional components which the package doesn't need, we have two choices.

1. write tests wihtout thrid party code (code which is not a dependency of the package at all)

2. write tests and depend on third party code but move the dependency to extra_requires. This allows to install the app without the additional test dependency

What do you think?

Even better: use the documented setuptools keyword[1] 'tests_require', and get the testrunner / buildout to use that hook when running tests. An added benefit is that it might even be possible for somebody to run the tests from a subversion checkout / unpacked sdist without first running buildout, by just running 'python setup.py test'. This last will require defining a workable 'test_suite' keyword, as well. [1] http://peak.telecommunity.com/DevCenter/setuptools#id7 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 iD8DBQFIAWlw+gerLs4ltQ4RAuq1AJ48SsGtuCUvBzTN2a1YLqGSPTBIfgCcC9ZQ GwLUzQDm6FQB6DpQ6a2bJkM= =hqQm -----END PGP SIGNATURE-----

On Apr 12, 2008, at 10:01 PM, Tres Seaver wrote:

Even better: use the documented setuptools keyword[1] 'tests_require', and get the testrunner / buildout to use that hook when running tests.

This doesn't address the central point that testing a different software configuration in testing than will be used in production can lead to unpleasant surprises in production. As to tests_require, unfortunately, it can't be used by buildout or any other setuptools-based application because it's presence isn't reflected in egg info. :( This is why people who want to provide test dependencies have been forced to use test extras. (tests_require is only usable by the test runner setup command. See http://mail.python.org/pipermail/distutils-sig/2007-January/007082.html FWIW, I think using test extras is a necessary evil when testing dependencies are significant. I wouldn't use it just to avoid a dependency on zope.testing, but I would and have used test extras to avoid more extensive dependencies. Jim -- Jim Fulton Zope Corporation

On Sun, Apr 13, 2008 at 12:25:46PM -0400, Jim Fulton wrote:

On Apr 12, 2008, at 10:01 PM, Tres Seaver wrote:

...

Even better: use the documented setuptools keyword[1] 'tests_require', and get the testrunner / buildout to use that hook when running tests.

This doesn't address the central point that testing a different software configuration in testing than will be used in production can lead to unpleasant surprises in production.

Fullack. @Roger: I think you might have misunderstood the flying-versus-testing argument. *Any* change in the software configuration that makes the test environment differ from the production environment raises the risk of getting unexpected errors. As the world isn't just black and white the two extremes (no just-for-test dependencies in production versus all-even-just-for-test dependencies in production) could be spelled out like this: - Minimize the amount of special dependencies that only your testing code needs. (Only get a new dependency for a test if it's really worth it. `zope.testing` is an example.) - Maximize the amount of dependencies that are shared within testing and production. (Carrying over `zope.testing` into production is an example as well.)

As to tests_require, unfortunately, it can't be used by buildout or any other setuptools-based application because it's presence isn't reflected in egg info. :( This is why people who want to provide test dependencies have been forced to use test extras. (tests_require is only usable by the test runner setup command.

See http://mail.python.org/pipermail/distutils-sig/2007-January/007082.html

FWIW, I think using test extras is a necessary evil when testing dependencies are significant. I wouldn't use it just to avoid a dependency on zope.testing, but I would and have used test extras to avoid more extensive dependencies.

+1 as well. One of my intentions here is to avoid getting zope.app.* dependencies in zope.* packages. However, in the long run, those dependencies probably should go away by reworking the tests or refactoring the (overall) code base. 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