-----BEGIN PGP SIGNED MESSAGE-----
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:
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):
line 394, in openInOrPlain
fp = open(filename)
IOError: [Errno 2] No such file or directory:
Ripping out the unused / unusable code which is sitting unused in the
Zope3 tree is *not* in scope for my proposal.
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v184.108.40.206 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -