-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Philipp von Weitershausen wrote:
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.
When we get there, I think the developer will install a single meta-egg, which then pulls down and installs the others. At that point, she will be working in the same environment as everyone else. When she wants to modify a package, she will check it out separately and run the 'develop' command, which will force the checkout onto her path as a "source egg". Maybe we'll even have a script available which makes this a simpler process.
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.
That will be good. Even after eliminating the list you provided (see below), there is still a lot of stuff in zope.app which is irrelevant to Zope2 (I think).
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.
I've created a new branch from the 3.2 branch which makes the changes I proposed: i.e. 'datetimeutils', 'timezones', and 'decorators' become packages, and their tests move from 'zope/app/tests/' to their own 'tests' subdirectory (none of those tests exported facilities used by any other tests.
All unit and functional tests pass on that branch, with identical results to the 3.2 tree.
I have also morphed the 'zope.app' package in my 'tseaver-retire_zpkg' branch to point into this new branch, eliminating the "dead" packages you described. The only "forked" code is the empty __init__.py, which seems an acceptable tradeoff. I added an EXTERNALS.txt file which documents the intended links.
BTW, a small nit of mine with subversion: can anybody tell me how to find the revision in which a directory was moved / removed, preferably via the web interface? Subversion doesn't seem to expose a way to ask about a name which, like the "man upon the stair" isn't there any more.
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).
Yup, the same general approach should work in the 2.10 tree.
I've now done the same work on a branch for that tree: [/home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10] $ head .svn/entries <?xml version="1.0" encoding="utf-8"?> <wc-entries xmlns="svn:"> <entry committed-rev="68857" name="" committed-date="2006-06-26T21:16:14.182239Z" url="svn+ssh://svn.zope.org/repos/main/Zope/branches/tseaver-retire_zpkg-2.10" last-author="tseaver" kind="dir" Note that here I used the contents of 'zope.app' as installed by the 2.10b1 tarball, which has at least one of the packages in it ('wfmc') which Philipp said should be excluded for 2.9. AFAIK, both of these branches are ready for merging to their respective branches (and to the trunk, for the 2.10 version). Comments? 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 iD8DBQFEoFIz+gerLs4ltQ4RApTFAKCRpYarfrxQcBkZAaTmFqYWemQ6ZQCghVpS aYhIXCIMVqta0V+LH9gD7Tc= =V2vf -----END PGP SIGNATURE-----