[Zope-dev] Re: SVN: Zope/branches/tseaver-retire_zpkg/ Note dropping of 'zpkg'; use a current version number.
Tres Seaver wrote: Log message for revision 68810: Note dropping of 'zpkg'; use a current version number. Changed: U Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt U Zope/branches/tseaver-retire_zpkg/setup.py -=- Modified: Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt === --- Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt 2006-06-23 23:30:41 UTC (rev 68809) +++ Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt 2006-06-24 03:03:22 UTC (rev 68810) @@ -18,6 +18,9 @@ Bugs fixed + - Returned to the classic './configure make make install' +recipe, dropping the use of 'zpkg' for building Zope2 releases. I don't think this is a bugfix :) + - OFS Application: Updated deprecation warnings. Support for '__ac_permissions__' and 'meta_types' will be removed in Zope 2.11, 'methods' support might remain longer. Modified: Zope/branches/tseaver-retire_zpkg/setup.py === --- Zope/branches/tseaver-retire_zpkg/setup.py2006-06-23 23:30:41 UTC (rev 68809) +++ Zope/branches/tseaver-retire_zpkg/setup.py2006-06-24 03:03:22 UTC (rev 68810) @@ -34,6 +34,7 @@ --install-platlib=/usr/local/lib/zope \ --install-purelib=/usr/local/lib/zope +ZOPE_VERSION = '2.9.4-alpha' Since you're denoting this as a current version number, do I take it that you're planning on changing the way Zope 2.9 and 2.10 releases are created as well? I would consider egg-based deployment a feature; at least it's a big enough change that I'd be worried for it to occur in a maintenance release. After all, zpkg *does* work and the way zpkg-based releases are installed *is* documented (hence protest against this being a bugfix). It just gives some people headaches (which is why I'm +1 to the overall idea). Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/tseaver-retire_zpkg/ Note dropping of 'zpkg'; use a current version number.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: Log message for revision 68810: Note dropping of 'zpkg'; use a current version number. Changed: U Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt U Zope/branches/tseaver-retire_zpkg/setup.py -=- Modified: Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt === --- Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt2006-06-23 23:30:41 UTC (rev 68809) +++ Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt2006-06-24 03:03:22 UTC (rev 68810) @@ -18,6 +18,9 @@ Bugs fixed + - Returned to the classic './configure make make install' +recipe, dropping the use of 'zpkg' for building Zope2 releases. I don't think this is a bugfix :) + - OFS Application: Updated deprecation warnings. Support for '__ac_permissions__' and 'meta_types' will be removed in Zope 2.11, 'methods' support might remain longer. Modified: Zope/branches/tseaver-retire_zpkg/setup.py === --- Zope/branches/tseaver-retire_zpkg/setup.py 2006-06-23 23:30:41 UTC (rev 68809) +++ Zope/branches/tseaver-retire_zpkg/setup.py 2006-06-24 03:03:22 UTC (rev 68810) @@ -34,6 +34,7 @@ --install-platlib=/usr/local/lib/zope \ --install-purelib=/usr/local/lib/zope +ZOPE_VERSION = '2.9.4-alpha' Since you're denoting this as a current version number, do I take it that you're planning on changing the way Zope 2.9 and 2.10 releases are created as well? I would consider egg-based deployment a feature; at least it's a big enough change that I'd be worried for it to occur in a maintenance release. After all, zpkg *does* work and the way zpkg-based releases are installed *is* documented (hence protest against this being a bugfix). It just gives some people headaches (which is why I'm +1 to the overall idea). We've had zpkg-related bugs after *each* Zope 2.9 release; there are a couple of open ones now for 2.10. Andreas, as release manager, doesn't like zpkg or want to continue using it. I don't see this as a new feature: in fact, it restores some old features (e.g., out-of-tree builds) lost in the switch to zpkg. I agree that Bugs Fixed is not appropriate. We can reclassify it in the changelog as Other Changes, or soemthing. I would argue that the patch is minimal enough to apply to 2.9.4 and 2.10 final without significant risk. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEnSzU+gerLs4ltQ4RAmXIAKCzDaHnVhVjx53xvcGELLzoN5T/gQCeOXyd Bh7NITbF1N7CyXjFCklZuXg= =p580 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: I worked last night with folks from the Fedora Extras project who were trying to package Zope 2.9.3 for FC5+. Because they were working from the release tarball, generated by 'zpkg', much of my knowledge about how the build process works (or doesn't) was invalid: - The Makefile generated by 'zpkg' does not have bugfixes / features which have been made to the 'Makefile' created by 'configure' in a checkout. - The 'install.py' script has subtly-different semantics from the 'setup.py' script in the checkout. In particular, it was hard to figure out how to get the installed libraries correct for the x86_64 package. - We have had a bunch of bugs since 2.9 related to the 'zpkg'-based build, some related to lost features and other to various kinds of breakage (see #1967, #1968, #1996, #2030, #2081, #2082, #2083, #2121). - Working inside the 'zpkg'-generated tarball is *very* confusing, even for experienced Zope developers: Where is the source? is a frequent cry in such cases. All of this is due to the fact that none of the maintainers of Zope2 is also a conusmer of the zpkg-gnereated releases; those consumers are the downstream packagers and sysadmins who have no idea how to work in that setup, and who can't even (easily) get help on it from the Zope developer community. 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, and that we should thus retire zpkg as the means for building Zope2 releases. Instead, we should recreate the version of the 'inst' stuff removed in the 2.9 beta cycle, and update it for any changes to the tree made since then. I volunteer to do the work, assuming the community concurs. 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. - I have made an 'sdist' tarball from the sandboxy, and then been able to run './configure ... make makd test make install' from the directory in which I unpacked the tarball. - I was also able to create an out-of-tree build from that unpacked directory. - Instances created from the tarball can run unit tests for their products via 'bin/zopectl test'. - The site starts up fine, and I can add content via the ZMI, etc. Remaining TODOs: - I would like to have a few more folks try out working with the tarball, which I have uploaded to zope.org: http://www.zope.org/Members/tseaver/Zope-2.9.4-retire_zpkg.tgz - I should find and update any documentation on making a release to reflect the new process. I don't think any of that documentation is in the source tree: does anyone have a pointer to it? - Make the corresponding changes to the Windows build machinery. Comments? Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEnUDU+gerLs4ltQ4RAr+hAJ9bw9T1PaBTc6JDUNdCdQTYVuFKcQCfcDFB Qe7cCO/QmBnF/92vPaPuFO8= =OEKK -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
Thanks a lot for your work! --On 24. Juni 2006 09:40:36 -0400 Tres Seaver [EMAIL PROTECTED] wrote: Remaining TODOs: - I would like to have a few more folks try out working with the tarball, which I have uploaded to zope.org: http://www.zope.org/Members/tseaver/Zope-2.9.4-retire_zpkg.tgz Works fine for me. I don't see any issues - Make the corresponding changes to the Windows build machinery. Perhaps we should check the Windows build machinery before merging the branch. It's easy to mess up the Windows stuff but it's hard to fix it :-) Andreas pgpCzhhzTE1F7.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6317 Blamelist: andreasjung,benji_york,ctheune,dominikhuber,hdima,jens,philikon,tseaver,yuppie BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
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? 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... Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/tseaver-retire_zpkg/ Note dropping of 'zpkg'; use a current version number.
Tres Seaver wrote: Since you're denoting this as a current version number, do I take it that you're planning on changing the way Zope 2.9 and 2.10 releases are created as well? I would consider egg-based deployment a feature; at least it's a big enough change that I'd be worried for it to occur in a maintenance release. After all, zpkg *does* work and the way zpkg-based releases are installed *is* documented (hence protest against this being a bugfix). It just gives some people headaches (which is why I'm +1 to the overall idea). We've had zpkg-related bugs after *each* Zope 2.9 release; there are a couple of open ones now for 2.10. Indeed, I count three open issues, all related to test.py (http://www.zope.org/Collectors/Zope/2121 and the two it links to). Sounds like there's only one real issue behind them (wrong test.py). I would argue that the patch is minimal enough to apply to 2.9.4 and 2.10 final without significant risk. I disagree, but in the end it's your, Andreas's and whoever-else's call as to how the risk of switching in between minor releases is weighed against the number of problems we have with zpkg. There *are* significant semantic differences between a zpkg checkout and the one you produced, as pointed out by my other email a minute ago. Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Database mounting problem in 2.9.3?
Chris Withers wrote at 2006-6-23 17:12 +0100: Get this error on startup with one project I've just moved to Zope 2.9.3: File /usr/local/zope/2.9.3/lib/python/Zope2/Startup/datatypes.py, line 175, in createDB return ZODBDatabase.open(self, databases) File /usr/local/zope/2.9.3/lib/python/ZODB/config.py, line 105, in open databases=databases) File /usr/local/zope/2.9.3/lib/python/ZODB/DB.py, line 262, in __init__ raise ValueError(database_name %r already in databases % ValueError: database_name 'packed' already in databases You see here the new (ZODB 3.6) multi-database support. Something tries to ad the database packed to a multi-database that already contains a packed. This might happen when you mount the same storage at different places into your hierarchy. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 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...? Hmm, I tried './configure --with-python but there wasn't one, so I didn't even look for the Makefile. How do Zope3 developers cope with the
Re: [Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
On Sat, Jun 24, 2006 at 04:08:23PM +0200, Andreas Jung wrote: | - Make the corresponding changes to the Windows build machinery. | | | Perhaps we should check the Windows build machinery before merging the | branch. | It's easy to mess up the Windows stuff but it's hard to fix it :-) I can help some here. After all, building Zope on Windows fills 60% of my days lately so I'm very interested that this is as easy and has as little dependencies as possible. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
Tres Seaver wrote: 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). Agreed. By the way, I just compated a Zope 2.9.3 install with your tarball. The same comparison should be done again with the Zope 2.10b1 tarball as other zope.app packages might've made it into the Zope 2.10 release line. At least with explicit externals in zope.app we can avoid more zope.app junk sneaking into Zope 2 much better. 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. Ok. 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. I usually google to find the checkin email :). Hmm, I tried './configure --with-python but there wasn't one Right, it's a checkout. What's there to configure? (Besides the Python executable). so I didn't even look for the Makefile. How do Zope3 developers cope with the possibility that the user may need / want to use a different Python? Running 'make PYTHON=/path/to/my/python' works, but seems a little hard-core for the make-averse crowd that hands out on #zope3-dev. ;) Heh, but that's how we do it :) Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
