[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
Philipp von Weitershausen
philipp at weitershausen.de
Sat Jun 24 15:57:17 EDT 2006
Tres Seaver wrote:
> 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.
Ok. I'll note that Python eggs don't fulfill that goal of having a
development area look like a package or an installed version either.
> I'll agree that these items ought not to be in the Zope2 tree: fixing
> that *in the checkout* would be a worthwhile effort.
Indeed; in fact, we always wished they hadn't been there in the first
place. Of course, in the end we hope that zope.app won' thave to be in
Zope 2 at all anymore.
> 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.
Sounds like the simplest approach indeed. I'm +1. I'm -1 on moving
anything around other than turning modules into packages, though. Moving
things around bares risks of breaking something. We can't afford that
within a stable release series. Not moving the tests won't be a problem
because zope.app tests aren't run in Zope 2 anyways. If they were run
we'd get lots of failures anyways, because zope.app stuff is quite
interwoven.
Also note that all of the above have been deprecated in Zope 3.3/2.10
(datetimeutils, decorator and timezones have been moved to the zope.*
level, servicenames has been made obsolete).
> 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'
Looks like you forgot to run 'make' to get the ZCML stuff installed into
zopeskel...?
> Ripping out the unused / unusable code which is sitting unused in the
> Zope3 tree is *not* in scope for my proposal.
Agreed.
Philipp
More information about the Zope-Dev
mailing list