[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