-----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 [EMAIL PROTECTED] 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----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )