[Zope-dev] Dependencies and future of zope 3

[Tres Seaver]

-----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 at 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-----