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