-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Pratt wrote:
Hey Roger. Sounds reasonable to me. Can we also discuss the potential of only including testing setup for dev eggs and removing testing as part of a release when the eggs are packaged to pypi or other repository for consumption.
Besides loosing the dependency, this makes for happier folks external to zope that consume our eggs.
- -1 to removing the tests from distributions (which should nearly always be 'sdists', rather than eggs). Consumers should be *able* to run tests, if desired, but they shouldn't have to pay the price for the testrunner unless they choose too: "pay for what you eat." The change under discussion about testing is whether or not to remove the test requirements as part of 'install_requires' in setup.py. Some folks have objecctions to using the setuptools-provided 'tests_require' field, although I think the argument there is weak: packages which spell 'tests_require' and 'test_suite' in their setup can be tested trivially with 'python setup.py test', which seems a win to me. I'm not volunteering to write it, but it strikes me as odd that folks haven't morphed zc.buildout (and / or associated recipes) to use this field. I *did* write a setuptools add on which saved the 'tests_require' info into the EGG_INFO directory: that package could be used to capture the metadata during installation of packages, for consumption by a testrunner later. I discovered today I think the time is ripe for a "blank buffer" rewrite of the testrunner: it is so full of "twisty passages" that my confidence in its own internal correctness is seriously depleted. It has too many features, and too many incompatible ways to run it: I would love a simpler version, whose discovery logic used egg metadata instead of (mal)heuristics (e.g., ordering of '--test-path' and '--package-path' arguments can make some tests unfindable).
While I personally do not like the contributor agreement, I am willing to sign to help out to work with you and others to get this settled. I am busy just like anyone else, but this stuff with the dependencies has to end now. Weve been with eggs for more than a couple years, progress has been made but it has been slow. Seriously, let's see what we can do to.
The browser packages are a good place to start. Testing another. Third would be seriously examining dependencies of core again once this is done. Fourth might be tackling some of the zope.xxx zope.app.xxx' relationships. Some of the stale packages in the main repository and placing them at another location if they are unmaintained might also be in order.
If we want to folks to use zope we need to be friendly to wsgi with or without a zodb and show both sides of the coin - that CA + choice of backend + zope security + choice of traversal method (with publisher) == interesting, productive, mature, dynamic and efficient.
Stripping away inessentials is always hard, with layering and good dependency management the only sane path forward. 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 iD8DBQFIvy3M+gerLs4ltQ4RAkFFAKDbUVHergvl7EllWy9uP02odeerfwCgryNb qL7CY7DAVGqeEUKxpnBJ5CY= =NUwO -----END PGP SIGNATURE-----