-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
Tres Seaver wrote:
I believe that the extra flexibility which zpkg is intended to provide (dependency-based subset distributions, primarily) would be better served by moving Zope to use eggs,
Where are the eggs, btw?
Not part of this proposal. I just want to use the same installation machinery as Zope2 has always used, and let the egg stuff sort out later.
I will be ready shortly to merge this branch to the 2.9 branch, the 2.10 branch, and the Zope2 trunk. Here is how I have tested it so far:
- All unit tests pass, with the same count (and deprecation warnings!) in my sandbox for this change as for the 2.9 head.
This doesn't surprise me. After all, you just tarred up the SVN export. zpkg actually only tars up what is explicitly selected to be released. Your tarball contains a few things that haven't been in Zope 2.9.x releases before, e.g.:
- zope.app.boston - zope.app.catalog - zope.app.css - zope.app.dav - zope.app.debugskin - zope.app.demo - zope.app.fssync - zope.app.homefolder - zope.app.i18nfile - zope.app.interpreter - zope.app.locking - zope.app.module - zope.app.observable - zope.app.pluggableauth - zope.app.presentation - zope.app.pythonpage - zope.app.recorder - zope.app.schemacontent - zope.app.securitypolicy - zope.app.server - zope.app.sqlexpr - zope.app.styleguide - zope.app.twisted - zope.app.versioncontrol - zope.app.wfmc - zope.app.winservice - zope.app.workflow - zope.app.zopetop
Most of these
a) have either never released even in Zope 3 (this is the majority),
b) are sample things (like css, styleguide, demo, etc.) that are (for the most part) bitrotting in zope.app
c) are so much core to Zope 3 that they don't make sense in Zope 2 (such as twisted, securitypolicy)
While b) and c) might not do much harm, the fact that things in a) *are* released now *does* make a new feature. Even worse, most of the things in category a) *should not* be release because they're considered broken or unstable. I agree that zope.app is horribly trashed with junk that doesn't belong in there (probably doesn't even belong inside the Zope 3 tree), but that's how it is right now. Just dumping it in a tarball isn't the way to go...
If it had been that trivial to NOT use zpkg back then, I certainly wouldn't have considered it at all...
The point is that the "release" tarball should generate the same environment that the developers routinely work in; otherwise, we leave the poor suckers who install from it stuck with whatever bugs are caused by the difference. I'll agree that these items ought not to be in the Zope2 tree: fixing that *in the checkout* would be a worthwhile effort. The simplest approach I can see to that would be: - On the Zope3 side, make it a rule that 'zope.app' contains only packages, not modules, converting the existing modules into packages with '__init__.py' corresponding to the current modules. Move the corresponding tests down into the new packages, as well. Currently, that would involve changing the following: o zope.app.datetimeutils o zope.app.decorator o zope.app.servicenames o zope.app.timezones Alternatively, if any of those modules is not used in Zope2 (it appears that 'datetimeutls' is the only one so used, except that it uses 'timezones'), we could leave them alone. - Make the 'app' directory on the zope2 side a non-external, containing its own externals pointing to the packages we want to ship with Zope2. I don't think this should be too hard, except for the fact that I don't know how to run the functional tests on the Zope3 side: $ ../bin/python2.4 test.py -m zope.app Running unit tests: Ran 3659 tests with 0 failures and 0 errors in 52.782 seconds. Running zope.app.testing.functional.Functional tests: Set up zope.app.testing.functional.Functional Traceback (most recent call last): ... File "/home/tseaver/projects/Zope-CVS/Zope-3_2-branch/src/zope/configuration/xmlconfig.py", line 394, in openInOrPlain fp = open(filename) zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/home/tseaver/projects/Zope-CVS/Zope-3_2-branch/zopeskel/etc/ftesting.zcml", line 20.2-20.40 IOError: [Errno 2] No such file or directory: '/home/tseaver/projects/Zope-CVS/Zope-3_2-branch/zopeskel/etc/securitypolicy.zcml' Ripping out the unused / unusable code which is sitting unused in the Zope3 tree is *not* in scope for my proposal. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEnZSz+gerLs4ltQ4RArw6AJ9LWK9/e3Roi68HDUxZppVENMKdRQCgk08A FXL+LjWC0zVpWWXclbXWzX4= =uSyp -----END PGP SIGNATURE-----