[Zope-dev] Heads up: Branch naming scheme
Hi there, quick reminder for all of you who have Zope 2.9 branch checkouts: There has been a change (finally!) in the release branch naming scheme. The 2.9 branch was renamed to Zope/branches/2.9 as a result. This will be the naming scheme for all release branches in Zope 2 and 3 from now on. Please switch your Zope 2.9 working copies to the new location with: $ svn switch svn+ssh://[EMAIL PROTECTED]/repos/main/Zope/branches/2.9 Have a good weekend, 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-Checkins] SVN: Zope/trunk/releases/Zope2. Name the root collection simply Zope so that the name of the tarball will
Log message for revision 40158: Name the root collection simply Zope so that the name of the tarball will be decent. This doesn't conflict with the collection representing the 'zope' package because the *root* collection and a dependency of it never have to coexist as sibling directories somewhere; so no danger of problems due to case ignorant file systems. Changed: U Zope/trunk/releases/Zope2.cfg U Zope/trunk/releases/Zope2.map -=- Modified: Zope/trunk/releases/Zope2.cfg === --- Zope/trunk/releases/Zope2.cfg 2005-11-16 16:07:39 UTC (rev 40157) +++ Zope/trunk/releases/Zope2.cfg 2005-11-16 16:18:58 UTC (rev 40158) @@ -3,4 +3,4 @@ build-application yes collect-dependencies yes resource-map Zope2.map -default-collectionZope2-src +default-collectionZope Modified: Zope/trunk/releases/Zope2.map === --- Zope/trunk/releases/Zope2.map 2005-11-16 16:07:39 UTC (rev 40157) +++ Zope/trunk/releases/Zope2.map 2005-11-16 16:18:58 UTC (rev 40158) @@ -74,4 +74,4 @@ # project; they define what goes into the Zope 2 and related # releases. # -Zope2-src ../releases/Zope2 +Zope ../releases/Zope2 ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/Zope-2_9-branch/releases/Zope2. Merge r40158 from the trunk:
Log message for revision 40159: Merge r40158 from the trunk: Name the root collection simply Zope so that the name of the tarball will be decent. This doesn't conflict with the collection representing the 'zope' package because the *root* collection and a dependency of it never have to coexist as sibling directories somewhere; so no danger of problems due to case ignorant file systems. Changed: U Zope/branches/Zope-2_9-branch/releases/Zope2.cfg U Zope/branches/Zope-2_9-branch/releases/Zope2.map -=- Modified: Zope/branches/Zope-2_9-branch/releases/Zope2.cfg === --- Zope/branches/Zope-2_9-branch/releases/Zope2.cfg2005-11-16 16:18:58 UTC (rev 40158) +++ Zope/branches/Zope-2_9-branch/releases/Zope2.cfg2005-11-16 16:20:27 UTC (rev 40159) @@ -3,4 +3,4 @@ build-application yes collect-dependencies yes resource-map Zope2.map -default-collectionZope2-src +default-collectionZope Modified: Zope/branches/Zope-2_9-branch/releases/Zope2.map === --- Zope/branches/Zope-2_9-branch/releases/Zope2.map2005-11-16 16:18:58 UTC (rev 40158) +++ Zope/branches/Zope-2_9-branch/releases/Zope2.map2005-11-16 16:20:27 UTC (rev 40159) @@ -74,4 +74,4 @@ # project; they define what goes into the Zope 2 and related # releases. # -Zope2-src ../releases/Zope2 +Zope ../releases/Zope2 ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope3-dev] Re: [Zope-dev] Re: branched Zope 2.9
Andreas Jung wrote: --On 16. November 2005 14:03:05 -0500 Jim Fulton [EMAIL PROTECTED] wrote: Does this mean that the existing 2.9 branch needs to be removed and that the trunk remains frozen? Didn't Florent delete the branch? Obviously he did not as I assumed. So in this case Philipp needs to commit his fixes to the existing 2.9 branch and the HEAD and the HEAD would be open for new code. Yes, I comitted all the changes to both the trunk and the Zope 2.9 branch. They should be identical. So at this point I don't care whether we get rid of it again and recreate it at a later point or simply leave it. Again, Andreas' call. Note that most of the work I still need to do is happening in the zpkg code, so the Zope code is basically ready for a release. The only things I have on my todo list for Zope 2 are: - stitch in more things from Zope 3 so that ALL unit tests pass (this will effectively mean stitching in twisted, maybe even more). - make some CHANGES.txt entries ;) 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-Checkins] SVN: Zope/trunk/releases/Zope2/SETUP.cfg Only include *.py files for the scripts (in particular, DON'T include
Log message for revision 40126: Only include *.py files for the scripts (in particular, DON'T include the ZODBTools directory which was previously caught up in the '*' glob and confused zpkgsetup). Also include ZODBTools scripts (again, only *.py files). Changed: U Zope/trunk/releases/Zope2/SETUP.cfg -=- Modified: Zope/trunk/releases/Zope2/SETUP.cfg === --- Zope/trunk/releases/Zope2/SETUP.cfg 2005-11-15 14:54:47 UTC (rev 40125) +++ Zope/trunk/releases/Zope2/SETUP.cfg 2005-11-15 15:08:36 UTC (rev 40126) @@ -1,6 +1,7 @@ documentation doc/*.txt -scriptutilities/* +scriptutilities/*.py +scriptutilities/ZODBTools/*.py scriptzopetest data-files . ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/Zope-2_9-branch/releases/Zope2/SETUP.cfg Merge r40126 from the trunk:
Log message for revision 40127: Merge r40126 from the trunk: Only include *.py files for the scripts (in particular, DON'T include the ZODBTools directory which was previously caught up in the '*' glob and confused zpkgsetup). Also include ZODBTools scripts (again, only *.py files). Changed: U Zope/branches/Zope-2_9-branch/releases/Zope2/SETUP.cfg -=- Modified: Zope/branches/Zope-2_9-branch/releases/Zope2/SETUP.cfg === --- Zope/branches/Zope-2_9-branch/releases/Zope2/SETUP.cfg 2005-11-15 15:08:36 UTC (rev 40126) +++ Zope/branches/Zope-2_9-branch/releases/Zope2/SETUP.cfg 2005-11-15 15:13:24 UTC (rev 40127) @@ -1,6 +1,7 @@ documentation doc/*.txt -scriptutilities/* +scriptutilities/*.py +scriptutilities/ZODBTools/*.py scriptzopetest data-files . ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-dev] Re: SVN: Zope/trunk/test.py Don't hard-wire forward-slash into sys.path (redux).
Tres Seaver wrote: Log message for revision 40092: Don't hard-wire forward-slash into sys.path (redux). Please don't forget to merge this and the previous rev to the Zope 2.9 branch. From now on, both the trunk and the 2.9 branch need to be taken care of. 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: branched Zope 2.9
Florent Guillaume wrote: BTW I'm for removing the 2.9 branch for now. You didn't, so I presume 2.9 branch stays? It's important to clear the status of this branch because bugfixes need to be merged to it (see my email about Tres' bugfix, for example). By the way, in the future, just to avoid confusion, I think release branches should be made by the release manager (in thise case Andreas Jung). They clearly fall under their responsibility and supervision. I still think it was a good thing to create the branch now because I agree with Tres' general argument that a feature freeze on the trunk hinders on-going development. The trunk should never be in any freeze state. That's what release branches are for. Thus, the Zope 2.9 and 3.2 branches should have been made November 1st. 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] Re: branched Zope 2.9
Andreas Jung wrote: --On 15. November 2005 00:20:00 +0800 Philipp von Weitershausen [EMAIL PROTECTED] wrote: Florent Guillaume wrote: BTW I'm for removing the 2.9 branch for now. You didn't, so I presume 2.9 branch stays? It's important to clear the status of this branch because bugfixes need to be merged to it (see my email about Tres' bugfix, for example). By the way, in the future, just to avoid confusion, I think release branches should be made by the release manager (in thise case Andreas Jung). They clearly fall under their responsibility and supervision. Jup. So when I see clear the only problem is the zpkg issue (where Philikon is working on it)...right? Jup. Making progress in babysteps. 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-Checkins] SVN: Zope/trunk/lib/python/ use a specific revision of the Zope 3 trunk for now until we have some sort of tag
Log message for revision 40048: use a specific revision of the Zope 3 trunk for now until we have some sort of tag available (e.g. a Zope 3.2 beta tag). Changed: _U Zope/trunk/lib/python/ _U Zope/trunk/lib/python/zope/ -=- Property changes on: Zope/trunk/lib/python ___ Name: svn:externals - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1 BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/BTrees persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/persistent ThreadedAsync svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ThreadedAsync transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/transaction ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ZEO ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ZODB ZopeUndo svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ZopeUndo zdaemon-r 39732 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz zodbcode svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1 BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/BTrees persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/persistent ThreadedAsync svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ThreadedAsync transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/transaction ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ZEO ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ZODB ZopeUndo svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b3/src/ZopeUndo zdaemon-r 39732 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz -r 40034 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz zodbcode -r 40034 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode Property changes on: Zope/trunk/lib/python/zope ___ Name: svn:externals - app svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/app cachedescriptors svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/cachedescriptors componentsvn://svn.zope.org/repos/main/Zope3/trunk/src/zope/component configuration svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/configuration documenttemplate svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/documenttemplate eventsvn://svn.zope.org/repos/main/Zope3/trunk/src/zope/event exceptions svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/exceptions hookable svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/hookable i18n svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/i18n i18nmessageid svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/i18nmessageid interfacesvn://svn.zope.org/repos/main/Zope3/trunk/src/zope/interface modulealias svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/modulealias pagetemplate svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/pagetemplate proxysvn://svn.zope.org/repos/main/Zope3/trunk/src/zope/proxy publishersvn://svn.zope.org/repos/main/Zope3/trunk/src/zope/publisher schema svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/schema security svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/security server svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/server structuredtext svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/structuredtext tal svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/tal talessvn://svn.zope.org/repos/main/Zope3/trunk/src/zope/tales testing -r39830 svn://svn.zope.org/repos/main/zope.testing/trunk/src/zope/testing thread svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/thread deprecation svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/deprecation dottedname svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/dottedname formlib svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/formlib indexsvn://svn.zope.org/repos/main/Zope3/trunk/src/zope/index + app -r 40034 svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/app cachedescriptors -r 40034 svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/cachedescriptors component-r 40034 svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/component configuration-r 40034 svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/configuration documenttemplate -r 40034 svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/documenttemplate event-r 40034 svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/event exceptions -r 40034 svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/exceptions hookable -r 40034
[Zope-dev] Re: SVN: Zope/trunk/lib/python/AccessControl/ - converted interface to z3 interface.
yuppie wrote: Philipp von Weitershausen wrote: Log message for revision 39903: - converted interface to z3 interface. Changed: D Zope/trunk/lib/python/AccessControl/IUserFolder.py I think we should maybe leave the Zope 2 interfaces around for at least one release. People with custom user folder implementations might have imported this old Zope 2 interface. This change will break their products. In general I agree. But IStandardUserFolder in IUserFolder.py wasn't a Zope 2 interface. It was a quite useless base class. Hah, I didn't see that even. The leading 'I' was quite misleading then... If any custom user folder subclasses from that class - which I don't believe - removing that base class is all that has to be done to fix that product. True, but it wouldn't have been different if it were an interface. You're probably right, though, the chance that someone's using this interface is close to none. But if people think we should anyway give a warning first I'm fine with re-adding that file on the trunk. I don't have Zope 2 user folders subclassing, so I wouldn't be the one to complain ;). 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/trunk/lib/python/AccessControl/ - converted interface to z3 interface.
Yvo Schubbe wrote: Log message for revision 39903: - converted interface to z3 interface. Changed: D Zope/trunk/lib/python/AccessControl/IUserFolder.py I think we should maybe leave the Zope 2 interfaces around for at least one release. People with custom user folder implementations might have imported this old Zope 2 interface. This change will break their products. By the way, thanks for converting many interfaces to Zope 3 ones. For the Zope 2 ones that we're keeping around for a little while before throwing them out, have you thought about issuing deprecation warnings? zope.deprecation provides a very nice and easy to use framework for this. See zope.i18nmessageid/__init__.py for an example. 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: zope.app stitching
Jim Fulton wrote: We need to stitch zope.app into Zope 2 more carefully than we are now. Much of what we are stitching is unreleased in Zope3 and depends on things not stitched nto Zope 2. Among other things, this means that we can't use python2.4 test.py -m. to run all tests without getting test failures. It would be great if someone would sort this out before we do any Zope 2.9 releases. :) Well, from that vague we need to do it more carefully I deduce that you would like to stitch in zope.app like we stitch in zope, i.e. each package individually. Unfortunately, that will not work equally well because there are several text files at zope.app, more than just the __init__.py: DEPENDENCIES.cfg PACKAGE.cfg PUBLICATION.cfg browser.zcml configure.zcml content_types.py datetimeutils.py decorator.py ftesting.zcml menus.zcml meta.zcml servicenames.py timezones.py At least the Python modules and zpkgutils files will be needed in Zope 2 as well. The real problem is that svn:externals doesn't work on files, just on directories. So, we'd have to manage separate copies of those files. Are you sure we want to get into that? 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/trunk/ Merge philikon-zope32-integration branch. Basically, this branch entails:
yuppie wrote: * Moved to a zpkgutils-based build system, as the Zope 3.2 extension modules require to be built with it. If everything goes ahead as planned, the release tarball will also be built with zpkgutils (some work has also been done in that direction). That part seems to be work in progress. I needed some time and manual changes to set up an in-place instance for a fresh sandbox. What changes are those? A fresh Zope trunk checkout works for me. Here's what I did: $ svn co svn+ssh://[EMAIL PROTECTED]/repos/main/Zope/trunk Zope-trunk $ cd Zope-trunk $ ./configure $ make That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below). And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up. Not supported anymore is the right wording here. Basically, the configure; make; make install dance is going to go away for an SVN checkout. A simple Makefile as we have it in Zope 3 that simply provides shortcuts for in-place builds will probably replace it. We're not even sure if the configure dance makes sense for a release tarball. The only benefit of the ./configure script is that it (presumably) chooses the right Python for you, which isn't always what you want, anyways. At least I do ./configure --with-python=... more than half of the times. So I could just call python setup.py install with whatever Python I want in the first place. Similar problems are reported here: http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/12/compile/0 Is anybody working on resolving these issues? Well, problem is that I don't *see* this issue, so I wouldn't know how to do solve 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 )
[Zope-dev] Re: SVN: Zope/trunk/ Merge philikon-zope32-integration branch. Basically, this branch entails:
Philipp von Weitershausen wrote: That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below). Sorry, I meant $ python setup.py build_ext -i That's what make all does on Zope 3 and now on Zope 2 as well, it seems. And it's enough for an in-place build and IMHO all we need for an SVN checkout. 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] Re: SVN: Zope/trunk/ Merge philikon-zope32-integration branch. Basically, this branch entails:
Jim Fulton wrote: What changes are those? A fresh Zope trunk checkout works for me. Here's what I did: $ svn co svn+ssh://[EMAIL PROTECTED]/repos/main/Zope/trunk Zope-trunk $ cd Zope-trunk $ ./configure $ make That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below). You used to have to use make instance or make inplace to run the tests. These make commands no longer work. make inplace could probably be fixed by making it an alias for make build, since builds now seem to be in place. Good idea. And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up. Not supported anymore is the right wording here. Basically, the configure; make; make install dance is going to go away for an SVN checkout. A simple Makefile as we have it in Zope 3 that simply provides shortcuts for in-place builds will probably replace it. I don't think that you or I have the authority to decide this. You're quite right, I don't. I don't know what made me write this in indicative. Sorry for that. When Fred and I brainstormed about which implications a zpkg-based build for Zope 2 had, not being able to install out-of-place was one. Therefore the above paragraph should rather be read as a fact description, not an edict. IOW, rather than saying we're not going to support it anymore, I should really have said that the *current setup* doesn't support it which doesn't mean we can't bring it back. We're not even sure if the configure dance makes sense for a release tarball. The only benefit of the ./configure script is that it (presumably) chooses the right Python for you, which isn't always what you want, anyways. At least I do ./configure --with-python=... more than half of the times. So I could just call python setup.py install with whatever Python I want in the first place. It also lets you specify an install prefix. python setup.py install --home=prefix let's you do that too. More importantly, it is a familiar model for unix systems. True. It is an unfamiliar model for Python software, though. Anyways, I don't think the ./configure script is the issue right now and I certainly don't feel strongly about it. If you looked carefully at the log, you would have seen that it was doing make inplace, which you could easily verify doesn't work anymore. :) Ah, now I see it. I wasn't looking at the blue stuff on the top ;). Anyway, I've changed the buildbot setup to use just make and we are now getting successful builds and tests. Great! BTW, in case the tone of this message comes accross as negative, as others have said, we all really appreciate all of the great work you've done on getting Five 1.3 done and on getting Z3.2 into Z2! Thanks. I have to apologize for landing these features on the trunk without giving people a heads-up, though. I was eager to meet the feature-freeze deadline and didn't think about all the implications. 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-Annce] Five 1.2b and 1.3b released!
The Five team is happy to announce the release of two Five beta versions today, Five 1.2b and 1.3b! What is Five Five is a Zope 2 product that allows you to integrate Zope 3 technologies into Zope 2, today. Among others, it allows you to use Zope 3 interfaces, ZCML-based configuration, adapters, browser pages (including skins, layers, and resources), automated add and edit forms based on schemas, object events, as well as Zope 3-style i18n message catalogs. We've tried to keep the Five experience as close to Zope 3 as possible, so this means that what you learn while using Five should also be applicable to Zope 3, and viceversa. More information about Five can be found on our website, http://codespeak.net/z3/five/. Five 1.2 Five 1.2 is the last release line of Five to work with Zope 2.8 and its included Zope X3 3.0. It does not work on Zope 2.7 anymore (use Five 1.1 if you're bound to Zope 2.7) Compared to the 1.1 release a month ago, it introduces the following compelling list of new features: * Local site support Five now supports local sites in Zope 2. Sites are a concept known from Zope 3 and similar to CMF's sites (only that they can be nested). Thanks to Sidnei da Silva for the initial development back in March, Lennart Regebro and Philipp von Weitershausen for bringing it up to date for inclusion into Five 1.2. * Improved event support Five can now make standard Zope 2 containers (aka object managers) send Zope 3-style events for adding, moving, copying and deleting contained objects, instead of calling their manage_afterAdd, manage_beforeDelete, etc. methods. Thanks to Florent Guillaume for thinking through this non-trivial matter and implementing it. * Marker interfaces utility Five now includes a feature known from Zope X3 3.0's introspector, the ability to set marker interfaces on objects to influence their behaviour (such as view or adapter look-up). This also includes a browser page with a page template macro for doing so through-the-web. This feature is based on Sidnei da Silva's Plone-based product Flon. Thanks to him for the original implementation as well as Godefroid Chapelle, Whit Morriss and Yvo Schubbe for bringing it to Five 1.2. * Class registration through ZCML It is now possible to register Zope 2 classes through ZCML so that they show up in the ZMI as addable meta types. This basically obsolete's the boiler-plate ``initialize()`` function in products' ``__init__.py`` files, as well as equipping classes with a ``meta_type`` in the first place. Thanks to Yvo Schubbe for suggesting and implementing this great helper for cleaning out Zope 2 boiler plate code out of products. * New test runner Five 1.2 (and only 1.2) includes a forked copy of Zope 3.2's improved test runner which brings, among others, better doctest debugging and support for running tests on different levels and layers. Thanks to Tres Seaver for integrating this into Five 1.2. For more information please consult the CHANGES document: http://codespeak.net/z3/five/CHANGES.html Five 1.2b can be downloaded at http://codespeak.net/z3/five/release/Five-1.2b.tgz. Five 1.3 Five 1.3 is a straight port of Five 1.2 to Zope 3.2 which will be included in this December's Zope 2.9 release. Five 1.3 itself will also be part of Zope 2.9. It does not introduce any new features compared to Five 1.2, however, some restructuring has been made: * Most of the event work has been folded into Zope 2. That means that Zope 2.9 will ship with event-enabled object managers out of the box! * Several legacy packages were removed from Five as they are now included in Zope 2, such as Zope 3-style interfaces for OFS et.al. as well as the new test runner We are not providing a downloadable tarball of Five 1.3b. Instead it has been integrated into Zope 2.9 with which it will ship. To try out Zope 2.9, you have to currently check out the Zope 2 trunk from the subversion repository. About the Zope 3 Base - Five is part of the *Zope 3 Base* project, which aims to offer an approachable area for developers of Zope 3 related software. More about the Zope 3 base and its projects can be found on the project website, http://codespeak.net/z3/. ___ Zope-Announce maillist - Zope-Announce@zope.org http://mail.zope.org/mailman/listinfo/zope-announce Zope-Announce for Announcements only - no discussions (Related lists - Users: http://mail.zope.org/mailman/listinfo/zope Developers: http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/releases/Zope2/SETUP.cfg the skeleton dir is called differently in zope 2
Log message for revision 39813: the skeleton dir is called differently in zope 2 Changed: U Zope/branches/philikon-zope32-integration/releases/Zope2/SETUP.cfg -=- Modified: Zope/branches/philikon-zope32-integration/releases/Zope2/SETUP.cfg === --- Zope/branches/philikon-zope32-integration/releases/Zope2/SETUP.cfg 2005-11-01 15:08:33 UTC (rev 39812) +++ Zope/branches/philikon-zope32-integration/releases/Zope2/SETUP.cfg 2005-11-01 15:09:40 UTC (rev 39813) @@ -4,5 +4,5 @@ scriptzopetest data-files . - zopeskel + skel /data-files ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/releases/Zope2.map whitespace
Log message for revision 39814: whitespace Changed: U Zope/branches/philikon-zope32-integration/releases/Zope2.map -=- Modified: Zope/branches/philikon-zope32-integration/releases/Zope2.map === --- Zope/branches/philikon-zope32-integration/releases/Zope2.map 2005-11-01 15:09:40 UTC (rev 39813) +++ Zope/branches/philikon-zope32-integration/releases/Zope2.map 2005-11-01 15:53:03 UTC (rev 39814) @@ -51,7 +51,7 @@ ZClasses ../lib/python/ZClasses ZPublisher../lib/python/ZPublisher ZServer ../lib/python/ZServer -ZTUtils ../lib/python/ZTUtils +ZTUtils ../lib/python/ZTUtils Zope ../lib/python/Zope Zope2 ../lib/python/Zope2 ZopeUndo ../lib/python/ZopeUndo ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/releases/Zope2.map fix up the syntax of this thing.
Log message for revision 39810: fix up the syntax of this thing. also removed duplicate entry on docutils Changed: U Zope/branches/philikon-zope32-integration/releases/Zope2.map -=- Modified: Zope/branches/philikon-zope32-integration/releases/Zope2.map === --- Zope/branches/philikon-zope32-integration/releases/Zope2.map 2005-11-01 14:51:53 UTC (rev 39809) +++ Zope/branches/philikon-zope32-integration/releases/Zope2.map 2005-11-01 14:52:39 UTC (rev 39810) @@ -1,4 +1,4 @@ -# These packages are the Zope 3 components. +# These packages are the Zope 2 components. # docutils ../lib/python/docutils pytz ../lib/python/pytz @@ -18,51 +18,50 @@ ZEO ../lib/python/ZEO ZODB../lib/python/ZODB -RestrictedPython ../lib/python/RestrictedPython -ZConfig ../lib/python/ZConfig -zdaemon ../lib/python/zdaemon +RestrictedPython ../lib/python/RestrictedPython +ZConfig ../lib/python/ZConfig +zdaemon ../lib/python/zdaemon -AccessControl ../lib/python/AccessControl -Acquisition ../lib/python/Acquisition -App ../lib/python/App -ComputedAttribute../lib/python/ComputedAttribute -DateTime../lib/python/DateTime -DocumentTemplate../lib/python/DocumentTemplate -ExtensionClass ../lib/python/ExtensionClass -Globals ../lib/python/Globals -HelpSys ../lib/python/HelpSys -ImageFile ../lib/python/ImageFile -Interface ../lib/python/Interface -Lifetime../lib/python/Lifetime -MethodObject../lib/python/MethodObject -Missing ../lib/python/Missing -MultiMapping../lib/python/MultiMapping -OFS ../lib/python/OFS -Persistence ../lib/python/Persistence -Products../lib/python/Products -Record ../lib/python/Record -Shared ../lib/python/Shared -Signals ../lib/python/Signals -StructuredText ../lib/python/StructuredText -TAL ../lib/python/TAL -Testing ../lib/python/Testing -ThreadLock ../lib/python/ThreadLock -TreeDisplay ../lib/python/TreeDisplay -ZClasses../lib/python/ZClasses -ZPublisher ../lib/python/ZPublisher -ZServer ../lib/python/ZServer -ZTUtils ../lib/python/ZTUtils -Zope../lib/python/Zope -Zope2 ../lib/python/Zope2 -ZopeUndo../lib/python/ZopeUndo -docutils../lib/python/docutils -initgroups ../lib/python/initgroups -nt_svcutils ../lib/python/nt_svcutils -reStructuredText../lib/python/reStructuredText -tempstorage ../lib/python/tempstorage -webdav ../lib/python/webdav -zExceptions ../lib/python/zExceptions -zLOG../lib/python/zLOG +AccessControl ../lib/python/AccessControl +Acquisition ../lib/python/Acquisition +App ../lib/python/App +ComputedAttribute ../lib/python/ComputedAttribute +DateTime ../lib/python/DateTime +DocumentTemplate ../lib/python/DocumentTemplate +ExtensionClass../lib/python/ExtensionClass +Globals ../lib/python/Globals +HelpSys ../lib/python/HelpSys +ImageFile ../lib/python/ImageFile +Interface ../lib/python/Interface +Lifetime ../lib/python/Lifetime +MethodObject ../lib/python/MethodObject +Missing ../lib/python/Missing +MultiMapping ../lib/python/MultiMapping +OFS ../lib/python/OFS +Persistence ../lib/python/Persistence +Products ../lib/python/Products +Record../lib/python/Record +Shared../lib/python/Shared +Signals ../lib/python/Signals +StructuredText../lib/python/StructuredText +TAL ../lib/python/TAL +Testing ../lib/python/Testing +ThreadLock../lib/python/ThreadLock +TreeDisplay ../lib/python/TreeDisplay +ZClasses ../lib/python/ZClasses +ZPublisher../lib/python/ZPublisher +ZServer ../lib/python/ZServer +ZTUtils ../lib/python/ZTUtils +Zope ../lib/python/Zope +Zope2 ../lib/python/Zope2 +ZopeUndo ../lib/python/ZopeUndo +initgroups../lib/python/initgroups +nt_svcutils ../lib/python/nt_svcutils +reStructuredText ../lib/python/reStructuredText +tempstorage ../lib/python/tempstorage +webdav../lib/python/webdav +zExceptions ../lib/python/zExceptions +zLOG ../lib/python/zLOG # These packages are the release collections based on the Zope 2 # project; they define what goes into the Zope 2 and related ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/releases/Zope2.map made the wrong one the module
Log message for revision 39817: made the wrong one the module Changed: U Zope/branches/philikon-zope32-integration/releases/Zope2.map -=- Modified: Zope/branches/philikon-zope32-integration/releases/Zope2.map === --- Zope/branches/philikon-zope32-integration/releases/Zope2.map 2005-11-01 16:13:32 UTC (rev 39816) +++ Zope/branches/philikon-zope32-integration/releases/Zope2.map 2005-11-01 16:29:00 UTC (rev 39817) @@ -52,8 +52,8 @@ ZPublisher../lib/python/ZPublisher ZServer ../lib/python/ZServer ZTUtils ../lib/python/ZTUtils -Zope ../lib/python/Zope -Zope2 ../lib/python/Zope2.py +Zope ../lib/python/Zope.py +Zope2 ../lib/python/Zope2 ZopeUndo ../lib/python/ZopeUndo initgroups../lib/python/initgroups nt_svcutils ../lib/python/nt_svcutils ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/lib/python/ update zconfig to 2.3.1 for a zpkg-related case sensitivity fix
Log message for revision 39771: update zconfig to 2.3.1 for a zpkg-related case sensitivity fix Changed: _U Zope/branches/philikon-zope32-integration/lib/python/ -=- Property changes on: Zope/branches/philikon-zope32-integration/lib/python ___ Name: svn:externals - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3 BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/BTrees persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/persistent ThreadedAsync svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ThreadedAsync transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/transaction ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZEO ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZODB ZopeUndo svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZopeUndo zdaemon-r 39732 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz zodbcode svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1 BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/BTrees persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/persistent ThreadedAsync svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ThreadedAsync transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/transaction ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZEO ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZODB ZopeUndo svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZopeUndo zdaemon-r 39732 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz zodbcode svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/lib/python/ Move to Zope 3.2 in the externals. Packages that are new in this since
Log message for revision 39740: Move to Zope 3.2 in the externals. Packages that are new in this since Zope X3 3.0 are: - pytz - zodbcode - zope.deprecation - zope.dottedname - zope.formlib - zope.index - zope.testbrowser Changed: _U Zope/branches/philikon-zope32-integration/lib/python/ _U Zope/branches/philikon-zope32-integration/lib/python/zope/ -=- Property changes on: Zope/branches/philikon-zope32-integration/lib/python ___ Name: svn:externals - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3 BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/BTrees persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/persistent ThreadedAsync svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ThreadedAsync transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/transaction ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZEO ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZODB ZopeUndo svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZopeUndo zdaemonsvn://svn.zope.org/repos/main/zdaemon/tags/zdaemon-1.1 + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3 BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/BTrees persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/persistent ThreadedAsync svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ThreadedAsync transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/transaction ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZEO ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZODB ZopeUndo svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZopeUndo zdaemonsvn://svn.zope.org/repos/main/zdaemon/tags/zdaemon-1.1 pytz svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz zodbcode svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode Property changes on: Zope/branches/philikon-zope32-integration/lib/python/zope ___ Name: svn:externals - app svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/app cachedescriptors svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/cachedescriptors component svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/component configuration svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/configuration documenttemplate svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/documenttemplate event svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/event exceptions svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/exceptions hookable svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/hookable i18n svn://svn.zope.org/repos/main/Zope3/tags/jim-fix-test-ZopeX3-3.0.1-Zope-2.8/src/zope/i18n i18nmessageid svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/i18nmessageid interface svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/interface modulealias svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/modulealias pagetemplate svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/pagetemplate proxy svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/proxy publisher svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/publisher schema svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/schema security svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/security server svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/server structuredtext svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/structuredtext tal svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/tal tales svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/tales testing -r39704 svn://svn.zope.org/repos/main/zope.testing/trunk/src/zope/testing thread svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope/thread + app svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/app cachedescriptors svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/cachedescriptors componentsvn://svn.zope.org/repos/main/Zope3/trunk/src/zope/component configuration svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/configuration documenttemplate svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/documenttemplate eventsvn://svn.zope.org/repos/main/Zope3/trunk/src/zope/event
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/buildsupport/ Let's try some zpkg integration. I'll probably fail miserably
Log message for revision 39741: Let's try some zpkg integration. I'll probably fail miserably Changed: A Zope/branches/philikon-zope32-integration/buildsupport/ -=- Property changes on: Zope/branches/philikon-zope32-integration/buildsupport ___ Name: svn:externals + zpkgsetup svn://svn.zope.org/repos/main/zpkgtools/trunk/zpkgsetup ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/ Stab at building through zpkgutils. I don't really know what I'm doing,
Log message for revision 39747: Stab at building through zpkgutils. I don't really know what I'm doing, though, so it doesn't work yet. Changed: A Zope/branches/philikon-zope32-integration/releases/ A Zope/branches/philikon-zope32-integration/releases/Zope2/ U Zope/branches/philikon-zope32-integration/releases/Zope2/DEPENDENCIES.cfg U Zope/branches/philikon-zope32-integration/releases/Zope2/PACKAGE.cfg U Zope/branches/philikon-zope32-integration/releases/Zope2/SETUP.cfg A Zope/branches/philikon-zope32-integration/releases/Zope2.cfg A Zope/branches/philikon-zope32-integration/releases/Zope2.map U Zope/branches/philikon-zope32-integration/setup.py -=- Copied: Zope/branches/philikon-zope32-integration/releases/Zope2 (from rev 39741, Zope3/trunk/releases/Zope) Modified: Zope/branches/philikon-zope32-integration/releases/Zope2/DEPENDENCIES.cfg === --- Zope3/trunk/releases/Zope/DEPENDENCIES.cfg 2005-10-30 17:10:32 UTC (rev 39741) +++ Zope/branches/philikon-zope32-integration/releases/Zope2/DEPENDENCIES.cfg 2005-10-30 17:56:52 UTC (rev 39747) @@ -4,29 +4,59 @@ # We'll start with a micro distribution, and add the commented out # things once we're confident the core is working. -zope.contentprovider -zope.viewlet +AccessControl +Acquisition +App +ComputedAttribute +DateTime +DocumentTemplate +ExtensionClass +Globals +HelpSys +ImageFile +Interface +Lifetime +MethodObject +Missing +MultiMapping +OFS +Persistence +Products +Record +RestrictedPython +Shared +Signals +StructuredText +TAL +Testing +ThreadLock +TreeDisplay +ZClasses +ZPublisher +ZServer +ZTUtils +Zope +Zope2 +ZopeUndo +docutils +initgroups +nt_svcutils +reStructuredText +tempstorage +webdav +zExceptions +zLOG + zope.app -zope.app.apidoc -zope.app.authentication -zope.app.dav -zope.app.debugskin -zope.app.dtmlpage -zope.app.file -zope.app.ftp -zope.app.generations -zope.app.i18nfile -zope.app.introspector -zope.app.mail -zope.app.onlinehelp -zope.app.pluggableauth -zope.app.rdb -zope.app.securitypolicy -zope.app.server -zope.app.session -zope.app.sqlscript -zope.app.tree -zope.app.undo -zope.app.zptpage -zope.app.catalog -zope.app.zptpage.textindex + +# zope.app depends for us on: +# - ZODB +# - persistent +# - transaction +# - zdaemon +# - zodbcode +# - ZConfig (indirectly) +# - ThreadedAsync (indirectly) +# - ZConfig (indirectly) +# - zdaemon (indirectly) +# - pytz (indirectly) Modified: Zope/branches/philikon-zope32-integration/releases/Zope2/PACKAGE.cfg === --- Zope3/trunk/releases/Zope/PACKAGE.cfg 2005-10-30 17:10:32 UTC (rev 39741) +++ Zope/branches/philikon-zope32-integration/releases/Zope2/PACKAGE.cfg 2005-10-30 17:56:52 UTC (rev 39747) @@ -1,10 +1,8 @@ load - LICENSES.txt svn://svn.zope.org/repos/main/Zope3/tags/*/LICENSES.txt - ZopePublicLicense.txt svn://svn.zope.org/repos/main/Zope3/tags/*/ZopePublicLicense.txt - bin/mkzopeinstance svn://svn.zope.org/repos/main/Zope3/tags/*/bin/mkzopeinstance - bin/mkzeoinstance svn://svn.zope.org/repos/main/Zope3/tags/*/bin/mkzeoinstance - doc svn://svn.zope.org/repos/main/Zope3/tags/*/doc/ - zopeskel svn://svn.zope.org/repos/main/Zope3/tags/*/zopeskel/ + bin/mkzopeinstance.py svn://svn.zope.org/repos/main/Zope/tags/*/utilities/mkzopeinstance.py + bin/mkzeoinstance.py svn://svn.zope.org/repos/main/Zope/tags/*/utilities/mkzeoinstance.py + doc svn://svn.zope.org/repos/main/Zope/tags/*/doc/ + skel svn://svn.zope.org/repos/main/Zope/tags/*/skel/ /load distribution Modified: Zope/branches/philikon-zope32-integration/releases/Zope2/SETUP.cfg === --- Zope3/trunk/releases/Zope/SETUP.cfg 2005-10-30 17:10:32 UTC (rev 39741) +++ Zope/branches/philikon-zope32-integration/releases/Zope2/SETUP.cfg 2005-10-30 17:56:52 UTC (rev 39747) @@ -1,8 +1,6 @@ -documentation LICENSES.txt -documentation ZopePublicLicense.txt documentation doc/*.txt -scriptbin/* +scriptutilities/* scriptzopetest data-files . Copied: Zope/branches/philikon-zope32-integration/releases/Zope2.cfg (from rev 39741, Zope3/trunk/releases/Zope.cfg) === --- Zope3/trunk/releases/Zope.cfg 2005-10-30 17:10:32 UTC (rev 39741) +++ Zope/branches/philikon-zope32-integration/releases/Zope2.cfg 2005-10-30 17:56:52 UTC (rev 39747) @@ -0,0 +1,6 @@ +# zpkg config file +# +build-application yes +collect-dependencies yes +resource-map Zope2.map +default-collectionZope2 Copied: Zope/branches/philikon-zope32-integration/releases/Zope2.map (from rev 39741, Zope3/trunk/releases/Zope.map) === ---
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/lib/python/ Bring zdaemon external up to speed with the trunk
Log message for revision 39748: Bring zdaemon external up to speed with the trunk Changed: _U Zope/branches/philikon-zope32-integration/lib/python/ -=- Property changes on: Zope/branches/philikon-zope32-integration/lib/python ___ Name: svn:externals - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3 BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/BTrees persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/persistent ThreadedAsync svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ThreadedAsync transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/transaction ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZEO ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZODB ZopeUndo svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZopeUndo zdaemonsvn://svn.zope.org/repos/main/zdaemon/tags/zdaemon-1.1 pytz svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz zodbcode svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3 BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/BTrees persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/persistent ThreadedAsync svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ThreadedAsync transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/transaction ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZEO ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZODB ZopeUndo svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b2/src/ZopeUndo zdaemon-r 39732 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz zodbcode svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/releases/zpkg-support.pth Don't let zpkgutils go on ZConfig cold turkey
Log message for revision 39749: Don't let zpkgutils go on ZConfig cold turkey Changed: A Zope/branches/philikon-zope32-integration/releases/zpkg-support.pth -=- Added: Zope/branches/philikon-zope32-integration/releases/zpkg-support.pth === --- Zope/branches/philikon-zope32-integration/releases/zpkg-support.pth 2005-10-30 18:01:28 UTC (rev 39748) +++ Zope/branches/philikon-zope32-integration/releases/zpkg-support.pth 2005-10-30 18:08:40 UTC (rev 39749) @@ -0,0 +1,8 @@ +# This allows the ZConfig checked out with Zope to be used by the zpkg +# code invoked by setup.py. +# +# If zpkg ever requires a different version of ZConfig than Zope +# provides as part of it's checkout, this file should be replaced by +# an svn:external to the required version. +# +../lib/python ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/philikon-zope32-integration/setup.py point setup.py to the right package location in zope 2.
Log message for revision 39751: point setup.py to the right package location in zope 2. And ... WOW. it works! Yay. Changed: U Zope/branches/philikon-zope32-integration/setup.py -=- Modified: Zope/branches/philikon-zope32-integration/setup.py === --- Zope/branches/philikon-zope32-integration/setup.py 2005-10-30 18:09:47 UTC (rev 39750) +++ Zope/branches/philikon-zope32-integration/setup.py 2005-10-30 18:12:17 UTC (rev 39751) @@ -1,6 +1,6 @@ # # -# Copyright (c) 2002 Zope Corporation and Contributors. +# Copyright (c) 2005 Zope Corporation and Contributors. # All Rights Reserved. # # This software is subject to the provisions of the Zope Public License, @@ -41,5 +41,5 @@ os.path.join(here, releases, Zope2, zpkgsetup.publication.PUBLICATION_CONF)) -context.walk_packages(src) +context.walk_packages(lib/python) context.setup() ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-dev] New mailinglist for Zope 3 translators
Hello all, [Sorry for the cross-post, please CC replies to zope3-i18n@zope.org only.] two months ago, I started an initiative [1] to translate Zope 3.1 using Ubuntu's Launchpad system [2]. Since then, I've received a lot of emails from numerous volunteers around the world and many of them made some excellent progress [3]. Thanks to everyone who contributed so far. A new mailinglist at zope3-i18n@zope.org will now help translators and developers like me to coordinate their work. For example, all those translations will have to be integrated back into the Zope 3.1 repository at some point which has to be coordinated somehow. Also, translators themselves will want to coordinate the work among them. The mailinglist will serve as a forum for discussing and coordinating things like that. So, if you're involved into Zope 3 translations OR if you would like to contribute something to Zope 3 by helping to translate it into your language, please subscribe to the new list [4]. If you have any questions, feel free to email me or even better the new list. Best regards Philipp [1] http://mail.zope.org/pipermail/zope3-dev/2005-August/015113.html [2] https://launchpad.net [3] https://launchpad.net/products/zope/+series/zope3.1/+pots/zope [4] http://mail.zope.org/mailman/listinfo/zope3-i18n ___ 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] New mailinglist for Zope 3 translators
Hello all, [Sorry for the cross-post, please CC replies to [EMAIL PROTECTED] only.] two months ago, I started an initiative [1] to translate Zope 3.1 using Ubuntu's Launchpad system [2]. Since then, I've received a lot of emails from numerous volunteers around the world and many of them made some excellent progress [3]. Thanks to everyone who contributed so far. A new mailinglist at [EMAIL PROTECTED] will now help translators and developers like me to coordinate their work. For example, all those translations will have to be integrated back into the Zope 3.1 repository at some point which has to be coordinated somehow. Also, translators themselves will want to coordinate the work among them. The mailinglist will serve as a forum for discussing and coordinating things like that. So, if you're involved into Zope 3 translations OR if you would like to contribute something to Zope 3 by helping to translate it into your language, please subscribe to the new list [4]. If you have any questions, feel free to email me or even better the new list. Best regards Philipp [1] http://mail.zope.org/pipermail/zope3-dev/2005-August/015113.html [2] https://launchpad.net [3] https://launchpad.net/products/zope/+series/zope3.1/+pots/zope [4] http://mail.zope.org/mailman/listinfo/zope3-i18n ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: MVC Approach
Thomas Adams wrote: Hi all, I'm a newbie to Zope, using version 2.7.3 (okay it is not the newest one) and I want to know if there is something like a MVC approach available for Zope, i.e. Model-View-Controller approach, as it is for instance in Java with the Struts framework from Apache. ... P.S: I don't know Zope 3 (Is that apossible answer of my questions?) Yes, Zope 3 has a MVC-like architecture. We call it the Component Architecture. It lets you separate responsibilities into different components (objects), e.g. content objects (they can be persistent, for example, or come from an RDBMS), views (e.g. browser views that produce HTML), adapters (enhance components with functionality), and utilities. For a structured introduction, see http://dev.zope.org/Zope3/ProgrammerTutorial or http://worldcookery.com. It is also possible to use Zope 3 style components in Zope 2 already, by using the Five product: http://codespeak.net/z3/five/. However, if you don't have any Zope 2 legacy, I can only recommend you start with Zope 3 from the beginning. Best regards, Philipp ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: last minute Zope 2.8.1 changes
yuppie wrote: If there are no objections, I'd like to merge two changes into the Zope-2_8-branch before 2.8.1 is released: 1.) Backports from zope.tal to TAL and a small modification of ustr: http://svn.zope.org/?rev=37613view=rev http://svn.zope.org/?rev=37614view=rev This is a fix needed by Five to handle massageIDs correctly. I don't expect any backwards compatibility issues. +1 2.) Backport of Interfaces.bridge from the Zope trunk: http://svn.zope.org/?rev=33270view=rev This is a new utility function for z2 - z3 interface migration. It doesn't change any existing code, so there should be no risk. I guess it would be useful for many products, at least CMF trunk could benefit from that bridging code. +1 Normally I would be hesitant about adding new features to a minor release; this case is different, though: - the bridge code seems to be completely isolated from anything else, so there's zero risk to jeopardize any existing code. - it will encourage people to write more Zope 3 style interfaces from the beginning. Currently Five's Zope 2 - Zope 3 bridging code encourages people to write more Zope 2 interfaces, often only to bridge them to Zope 3 ones. That clearly isn't the optimal way: Zope 3 interfaces are not only future-proof and more powerful but Zope 2 interfaces are also rarely needed at all (there are a couple of uses, e.g. in some catalog indexes, which is why we do need Zope 3 - Zope 2 bridging). 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] Re: working with urls
Nicholas Wieland wrote: First of all thanks everyone for the help, I've resolved my problems one after the other thanks to the suggestions I've found here. Now I'm rewriting urls by substituting the href attribute with custom data, and everything works fine. What I'd like is having an url like: myproduct/generate/20050301/PG2, and actually that's exactly what I've got. This url will make my app generate a pdf report for the ref_date 2005/03/01 and code PG2 (ref_date and code are internal data). Zope obviously maps the url as an object, but that's not what I want: I want to parse the url and use the ref_date and code data inside a generate method. You want to write a __bobo_traverse__ method for your class: def __bobo_traverse__(self, REQUEST, name): # do something with 'name' here. return an_object_that_is_to_be_published Philipp ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: [Z3lab] Nuxeo supports Zope Corp announces
kit blake wrote: Wow, what a difference two days makes. I heard about the ZF announcement by telephone two mornings ago, and I breathed a huge sigh of relief. It solves a problem we've been worrying about for years. It means we can sit across from a nervous IT director, and when he asks dubious questions about the steering and future of the Zope platform, we can say with certainty, It's in good hands. Reviewing the thread, I'm astonished at the negativity. C'mon, this is a *breakthrough*. It's a move that can ensure the future of Zope. Granted, it's prudent to be cautious, and there's a lot of work to be done, but it's a major step. Shouldn't we be using an Agile approach? As for structure and neutrality, I think decisions should be left up to the developers. If they're not on board, there won't be anything. I'm not much of a developer, I'm a manager, and I know that attempting to pull developers 'over a bridge' is a bad idea. Actually, I'm a vendor too. So wearing all these different stakeholder hats, I'm looking forward to the process. To be explicit: I'm prepared to invest in the future of Zope. I'm sorry if I led anyone believe that I view this process negatively. That is absolutely not the case. I'm as excited and relieved as you, Kit. I personally have been publicly supporting the idea of self-governance of the Zope community for some time now and all of this brings us a huge step closer to it. My concerns regarding the process (which might have interpreted as negativity towards the whole idea) were mainly oriented towards the way the initiation of the process is perceived. All of the self-governance we already have (e.g. zope.org collaboration and maintainance, Zope 3 development process, etc.) has been built up bottom-to-top, just like in any other open source community. Even the wish for self-governance of Zope itself came from the basis and has been expressed publicly since the Castle sprint or even longer. So, my remarks were purely there to state that the perception of this process being nothing but top-to-bottom (IOW, vendor-driven) were a limited view on things. As anything else is mere speculation, I'm looking forward to hearing more details from those who initiated the process. I am confident that everyone in the community will be invited to participate, so that in the end we can all say that we as a community made this happen. Best regards, see you on tuesday in IRC, 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: [Z3lab] Nuxeo supports Zope Corp announces
Jean-Marc Orliaguet wrote: This is really great news! I am going to start working at getting Chalmers to be one of the key players in the foundation which would make the foundation even more vendor-neutral. I am confident that this will go through. This almost sounds as if the Foundation isn't to be vendor-neutral from the start which is certainly not the intention of a foundation. What I like about other open source foundations (take the Plone Foundation from our community, for example) is that the members are developers, not companies. The developers govern themselves, every developer gets a vote. 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: [Z3lab] Nuxeo supports Zope Corp announces
Jean-Marc Orliaguet wrote: Philipp von Weitershausen wrote: Jean-Marc Orliaguet wrote: This is really great news! I am going to start working at getting Chalmers to be one of the key players in the foundation which would make the foundation even more vendor-neutral. I am confident that this will go through. This almost sounds as if the Foundation isn't to be vendor-neutral from the start which is certainly not the intention of a foundation. What I like about other open source foundations (take the Plone Foundation from our community, for example) is that the members are developers, not companies. The developers govern themselves, every developer gets a vote. Philipp Hi! I'm a bit confused, first of all Chalmers is a university, it is not a software vendor. I guess you're right. But then I don't understand how Chalmers as a key player would make the Foundation more neural with respect to software vendors, as you say above. Then when I look at the members of the Plone foundation ( http://plone.org/foundation/about/board/list ) I only see companies, I see *people*. If I remember correctly, the Plone Foundation even specifically says no to companies, just like the ASF. Of course, that doesn't mean that officers of the board in the foundation can't be employed somewhere... Btw, you're looking at the board. But still, they're just people, not companies. http://plone.org/foundation/members has the actual members list. These are the people that get to vote. As you can see, I'm in this list and I don't belong to any company. If this was company driven, I wouldn't have a vote. except that ZC is not represented. So even if every member gets a vote, how much does that vote count in the development process of Zope2, CMF and Zope3 ? Well, it counts. How much does a vote count when you vote for your parliament? Little. But it counts. 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] Re: [Z3lab] Nuxeo supports Zope Corp announces
Andreas Jung wrote: --On 17. Juni 2005 13:04:17 +0200 Philipp von Weitershausen [EMAIL PROTECTED] wrote: Jean-Marc Orliaguet wrote: This is really great news! I am going to start working at getting Chalmers to be one of the key players in the foundation which would make the foundation even more vendor-neutral. I am confident that this will go through. This almost sounds as if the Foundation isn't to be vendor-neutral from the start which is certainly not the intention of a foundation. What I like about other open source foundations (take the Plone Foundation from our community, for example) is that the members are developers, not companies. The developers govern themselves, every developer gets a vote. I strongly second that. A company driven or ruled foundation is likely not very much acceptable for the Zope community. Yes. I wonder, given their experience in bootstrapping a foundation (with all the legal complications etc.), has the Plone Foundation been solicited for helpful input? Wouldn't make much sense for us to go through the same difficult steps if there's someone within our community who has done it already... 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: [Z3lab] Nuxeo supports Zope Corp announces
Chris McDonough wrote: On Fri, 2005-06-17 at 07:52 -0400, Stephan Richter wrote: Also, I agree with Andreas and Philipp that developers should be members, not companies. Otherwise, how could I, as an independent developer, have a say? BTW, this is also positive for companies, since they can have several developers being members. In the proposed scenario, my one-man shop would have a lot of power compared to larger companies, such as ZC, Nuxeo, etc. +1 if only because... From what I read from Rob in an interview in LWN, membership to the foundation will be funded by membership dues. Given that any actual facts and further discussions involving ZC have been postponed to the IRC chat on tuesday (which I'm perfectly fine with), I'm surprised to hear that I have to read LWN, some external and not freely available source, for further details... 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-Annce] Five 1.0.1 released!
Five 1.0.1 released! The Five team is happy to release Five 1.0.1, a bugfix release for Five 1.0. The most important news is unicode support for add and edit forms; other minor fixes are included as well. Please consult the CHANGES_ for more details. .. _CHANGES: http://codespeak.net/z3/five/CHANGES.html Five 1.0.1 can be downloaded here: http://codespeak.net/z3/five/release/Five-1.0.1.tgz This version of Five will also be port of the upcoming Zope 2.8. About Five -- Five is a Zope 2 product that allows you to integrate Zope 3 technologies into Zope 2, today. It allows you to use the following parts of the Zope 3 component architecture within Zope 2: * Zope 3 interfaces * adapters * pages (views), including skins, layers and resources * edit and add forms, based on schemas * ZCML We've tried to keep the Five experience as close to Zope 3 as possible, so this means that what you learn while using Five should also be applicable to Zope 3. More information about Five can be found on our website, here: http://codespeak.net/z3/five/ We hope you'll join our mailing list and let hear from yourself! About the Zope 3 Base - Five is part of the *Zope 3 Base* project, which aims to offer an approachable area for developers of Zope 3 related software. More about the Zope 3 base and its projects can be found here: http://codespeak.net/z3/ ___ Zope-Announce maillist - Zope-Announce@zope.org http://mail.zope.org/mailman/listinfo/zope-announce Zope-Announce for Announcements only - no discussions (Related lists - Users: http://mail.zope.org/mailman/listinfo/zope Developers: http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: Zope 2.8, Five and Interfaces
Martijn Faassen wrote: Philipp von Weitershausen wrote: [snip] Right. Here's what we could do: 1. Copy Five's interface definitions over to Zope 2.8 (mostly to OFS.interfaces, I guess) where they are added as Zope 2 interfaces 2. Keep Five's (redudant) interface definitions. They can stay at their status quo (status Zope 2.7, that is). 3. Add five:bridge / calls for every interface so that Five's interfaces are automatically kept up-to-date with the Zope 2.8 ones. The bridges would override the ones defined in the module, potentially updating with newer definitions. The only thing that we need to take care of is fallback for Zope 2.7 where the Zope 2 interfaces don't exist yet. So you would have the Zope 2.8 interfaces exist in the Five.interfaces module? Well, no. Five.interfaces would stay as it is; it seems to be pretty accurate for Zope 2.7 (especially with yuppie's fixes, which should be merged to the Five-1.0 branch, btw). Some interfaces were added to Zope 2.8 and it would make sense to manage all of them in the Zope tree for the future, not the Five tree. However, when run within Zope 2.8, we want Five.interfaces to be most accurate, so we would install bridges in Zope 2.8 that bridge the Zope 2.8 interfaces to Five.interfaces. At least that was yuppie's latest idea andI think it's elegant. If not, we do have a compatibility problem. I don't think we will. Philipp P.S.: In case you're wondering why I haven't done any work on the Five wrt testing/i18n: My hard drive had a head crash, the laptop is in for repair :( This message was sent using IMP, the Internet Messaging Program. ___ 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: relocating Zope 2 core interfaces - a proposal
yuppie wrote: Proposed Solution = 1.) Adding ZCML that bridges existing z2 interfaces into the 'interfaces' module of their package. [Zope 2.8.0] +1 2.) Copying z3 interfaces from Five.interfaces to the 'interfaces' module of the corresponding package. Marking those in Five as Zope 2.7 backwards compatibility cruft. [Zope 2.8.0] +1 3.) Doing the same for Zope 2.7 with monkey patching code. [Five 1.0+] I assume here you mean patching in OFS.interfaces, webdav.interfaces etc... 4.) Making interfaces.zcml point to the new locations. [Five 1.0+] 5.) Adding unit tests that verify interfaces and implementations. [Zope 2.8.0] IMHO that's yagni. We actually don't use interfaces that much for verifying implementations anymore. I think their most common use in Zope 3/Five is documentation, API/schema specification, and easier spelling for security declarations. Risks = I can't see a way to provide backwards compatibility for Products.Five.interfaces.*, but as explained above I'm hopeful this doesn't break many Five products. How and where would we be backward incompatible? I assume that Five.interfaces would remain where it is, since its definitions are needed for your point 3) above. 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: [z3-five] relocating Zope 2 core interfaces - a proposal
yuppie wrote: Current State = Five (now part of Zope 2.8) ships with one big interfaces.py file that contains z3 interfaces for Zope 2 core classes. (There are also some five specific interfaces in that file, but they are not subject of this proposal.) interfaces.zcml states that Zope 2 implements these interfaces, but there are no tests to verify that and in fact many of these interfaces are broken in Five 1.0. (Yesterday I checked in some fixes to the Five trunk.) Note that they also need to be in the 1.0 branch, if this is to be in Zope 2.8. sarcasmMaybe it's better the interfaces are broken. That makes sure people don't use them extensively and might give us a chance to relocate them at a later point./sarcasm Seriously, you should merge your r11978 to the Five-1.0 branch.0 I grepped through CMFonFive, SilvaDocBook and SilvaFlexibleXML: None of them use these interfaces. I think there's some code inside the Five tests that might use them. There's also a chance someone else is using them, but admittedly the risk of breaking something doesn't seem too big. This does deserve to be called 1.1 though if we're breaking APIs (this would then derive from the 1.0 branch, not the Five trunk). Ok. I don't think we need to break backward compatability. We would just need to deprecate the Five.interfaces location. Basically, the goals are: * The solution needs to work with Zope 2.7 * Preferrably, the interface import spelling should be equal on both systems (which means a monkey on 2.7 is probably inevitable). * On 2.8 we want to have definitions of the z3-style interfaces in the Zope tree. * Five.interfaces and OFS.interfaces.*, etc. need to contain the exact *same* interfaces (same, not equal) on both systems at all times. * Five.interfaces should be deprecated as an import location in the long term. Proposed Solution = 1.) Adding ZCML that bridges existing z2 interfaces into the 'interfaces' module of their package. [Zope 2.8.0] 2.) Copying z3 interfaces from Five.interfaces to the 'interfaces' module of the corresponding package. Marking those in Five as Zope 2.7 backwards compatibility cruft. [Zope 2.8.0] 3.) Doing the same for Zope 2.7 with monkey patching code. [Five 1.0+] I don't understand this step; what are you proposing? It might be better to use the new locations also for Zope 2.7. But the interfaces don't exist in Zope 2.7, so we would have to inject them into Zope 2.7. Yup. In Zope 2.7, the OFS.interfaces, etc. modules would have to be injected and be filled with the definitions from Five.interfaces. This is why Five.interfaces needs to be kept around anyway. It would probably be a sharade to Five._interfaces which is only imported on demand... 4.) Making interfaces.zcml point to the new locations. [Five 1.0+] While in Zope 2.8, we could add 'implements' in the Zope 2 code directly, we don't need to do this from ZCML anymore. As you state below, there might be issues with mixing five:implements and implements(). But if there are no issues, I agree that using implements() would be better. five:implements (which is equal to using zope.interface.classImplements) and implements() can be mixed. The class will in the end implement both definitions. 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: relocating Zope 2 core interfaces - a proposal
Martijn Faassen wrote: yuppie wrote: [snip] This way, all the work that remains for me is to merge in Five 1.0 into Zope 2.8. My point is: Doing that in a backward compatible way is impossible. So we have to do it now or never. That's true, but it's not that difficult to ask people to change their ZCML files to point to new interfaces at some point in the future. I think the importance of doing the release on time weighs against any improvements in Five. Yes. I still don't see where the need for incompatability is. Maybe I'm just blind. Can someone explain? By the way, I've just merged in Five 1.0 into Zope 2.8 (which was a significant amount of work, due to all kinds of copyright headers being different). Cool. I can imagine that it was quite dificult. By the way, I think we should have yuppie's r11978 in it (which means we need it on Five-1.0 branch and a Five 1.0.1 release, probably). Gee, I would do the merge myself my laptop wasn't broken. I'm on a Windoze machine right now on which I quickly installed Thunderbird to be at least a little communicative :). 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: [z3-five] relocating Zope 2 core interfaces - a proposal
yuppie wrote: I don't think we need to break backward compatability. We would just need to deprecate the Five.interfaces location. Basically, the goals are: * The solution needs to work with Zope 2.7 * Preferrably, the interface import spelling should be equal on both systems (which means a monkey on 2.7 is probably inevitable). * On 2.8 we want to have definitions of the z3-style interfaces in the Zope tree. * Five.interfaces and OFS.interfaces.*, etc. need to contain the exact *same* interfaces (same, not equal) on both systems at all times. That's the point I missed! It's important because if someone registers a view for Five.interfaces.IObjectManager and OFS.ObjectManager.ObjectManager implements OFS.interfaces.IObjectManager, you'd want these to be the same... So we just need code like this at the end of Five.interfaces: try: # override IObjectManager with Zope 2.8 interface from OFS.interfaces import IObjectManager except ImportError: # monkey patch Zope 2.7 OFS ... Right? Yup, something like that. I'd prefer something like this, though:: try: # override IObjectManager with Zope 2.8 interface from OFS.interfaces import IObjectManager def monkey(): pass except ImportError: def monkey(): # monkey patch Zope 2.7 OFS and in Five.monkey, we do:: from Products.Five.interfaces import monkey as interfaceMonkey interfaceMonkey() That way all monkey are effectively executed from Five.monkey which is the convention. I do it like that on the philikon-i18n branch, too, if you want to see another example. * Five.interfaces should be deprecated as an import location in the long term. Fine. I no longer think we need to break backward compatibility. Good :). 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: relocating Zope 2 core interfaces - a proposal
yuppie wrote: 4.) Making interfaces.zcml point to the new locations. [Five 1.0+] 5.) Adding unit tests that verify interfaces and implementations. [Zope 2.8.0] IMHO that's yagni. We actually don't use interfaces that much for verifying implementations anymore. I think their most common use in Zope 3/Five is documentation, API/schema specification, and easier spelling for security declarations. ??? Who is 'we'? The Zope 3 developers. How do you make sure documentation and specification are in sync with the implementation? AFAICT verifyClass() is quite useful for that. Your unit test should exercise the whole API promised by an implementation anyway, so often an explicit interface check is redudant (of course, it can't hurt). verifyClass() per se isn't bad, it's in fact a useful indicator, but having that it as a *sole* measure whether a class fulfills an interface or not is not sufficient (plus, in many Zope cases, verifyObject is better because attributes may only be initialized in __init__). The point why I think it's YAGNI is that we know the Zope 2 implementations do implement the interfaces. After all, I derived the interfaces from the implementations by gutting out the code. And it's unlikely they'll change (although I might be wrong on this one, in which case you win :)). 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: relocating Zope 2 core interfaces - a proposal
yuppie wrote: Yes. I still don't see where the need for incompatability is. Maybe I'm just blind. Can someone explain? I no longer see a problem. If we make sure the Five interfaces and those in the Zope tree are the same, there are no incompatibilities. By the way, I've just merged in Five 1.0 into Zope 2.8 (which was a significant amount of work, due to all kinds of copyright headers being different). Can't we use the same headers for Five 1.0 and Zope 2.8? Both releases are ZPL 2.1, aren't they? Are there other things you did have to change? They're both ZPL 2.1, but the copyright statement is a different one. Bare Five is Copyright (c) Five contributors, code in the Zope repository is Copyright (c) Zope Corporation and contributors. Maybe we should just switch all of Five to the ZC header to make things easier? It wouldn't change much of legal impact, would it? Cool. I can imagine that it was quite dificult. By the way, I think we should have yuppie's r11978 in it (which means we need it on Five-1.0 branch and a Five 1.0.1 release, probably). Gee, I would do the merge myself my laptop wasn't broken. I'm on a Windoze machine right now on which I quickly installed Thunderbird to be at least a little communicative :). Sorry. I didn't think Martijn would merge in Five today. Please let me know if can help to put things straight. You just need to merge the revision to the Five-1.0 branch (using svn merge) and apply the diff (output of svn diff -r11977:11978) to the Zope repository (2.8 branch) using the Unix 'patch' program. 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: relocating Zope 2 core interfaces - a proposal
Tres Seaver wrote: Your unit test should exercise the whole API promised by an implementation anyway, so often an explicit interface check is redudant (of course, it can't hurt). verifyClass() per se isn't bad, it's in fact a useful indicator, but having that it as a *sole* measure whether a class fulfills an interface or not is not sufficient (plus, in many Zope cases, verifyObject is better because attributes may only be initialized in __init__). The point why I think it's YAGNI is that we know the Zope 2 implementations do implement the interfaces. After all, I derived the interfaces from the implementations by gutting out the code. And it's unlikely they'll change (although I might be wrong on this one, in which case you win :)). When writing test-first, I often start with only the 'verifyClass' test, and an empty interface. Then as I flesh out the interface, the test fails, reminding me to add the method / attribute. Yes, you still need tests for the semantics, but the conformance test is still valuable, because it tests the tests (an extra safety belt). Fair enough. Note the extra: it shouldn't be your only one. 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: relocating Zope 2 core interfaces - a proposal
Martijn Faassen wrote: yuppie wrote: By the way, I've just merged in Five 1.0 into Zope 2.8 (which was a significant amount of work, due to all kinds of copyright headers being different). Can't we use the same headers for Five 1.0 and Zope 2.8? Both releases are ZPL 2.1, aren't they? Are there other things you did have to change? Yes, some other things like taking out the monkey.py module, and some documentation differences. Did you tag Five when you merged? It would probably a good idea, that way continuous merging will be easier (since you can ... I want to get the headers in synch inside Five eventually, just didn't want to do it for Five 1.0. Yeah, I woudln't mind using the ZC header (I'm personally not too fond of it in its contents, but the advantages outweigh the disadvantages). We could do such change on the trunk at least. 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] Zope 2.8, Five and Interfaces
Tres Seaver wrote: I had a closer look at Zope 2.8's Five and I'm concerned about the fact that Five ships with redundant interface definitions: - redundant code is always a problem because it's hard to keep things in sync - the fact that Five is maintained in a different repository and should work with different Zope versions makes it almost impossible to change Zope interfaces in a consistent way So my questions are: 1.) Why are interfaces that are available as Zope 2 interfaces duplicated in Five/interfaces.py instead of bridged? Partially I suspect this reason is historical -- the Zope 2 interfaces were created by Philipp von Weitershausen before Tres implemented the bridging functionality. Correct. 2.) Could we move the interfaces that are currently not available as Zope 2 interfaces to the corresponding packages in Zope 2.8, using Five/interfaces.py just as an fallback for Zope 2.7 and old Five products? Maybe we need to spell out what the fallback would look like more clearly. If people agree that this is problem, I'd volunteer to help resolving it. It sounds like a reasonable idea, but it does introduce complications. This does mean we need a separate version of Five for merging into Zope 2.8. Another potential problem is that some Five-based code is also likely to stop working as the interface will change location (I'm not sure what bridge does in this respect; does it create a new location for the bridged interface?). The bridging code fabricates a new Z3 interface and bashes it into whatever module the directive specifies, so we could keep the same dotted names as the current interfaces. Right. Here's what we could do: 1. Copy Five's interface definitions over to Zope 2.8 (mostly to OFS.interfaces, I guess) where they are added as Zope 2 interfaces 2. Keep Five's (redudant) interface definitions. They can stay at their status quo (status Zope 2.7, that is). 3. Add five:bridge / calls for every interface so that Five's interfaces are automatically kept up-to-date with the Zope 2.8 ones. The bridges would override the ones defined in the module, potentially updating with newer definitions. The only thing that we need to take care of is fallback for Zope 2.7 where the Zope 2 interfaces don't exist yet. If you want to do this, yuppie, feel free to do it. I would even be ok for this to be done for the 1.0 branch, provided you also add it on the trunk. If the interfaces change location due to bridging, this also means Five + 2.7 code would be incompatible with Zope 2.8 code that makes use of Five. I'm a bit worried about doing it now as it will take time and testing effort, then again, if we are to do it, it would be better to start moving things around before we release Zope 2.8.. +1. I have an intent (but no time so far) to make the equivalent change for CMFonFive, as well. Cool. 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: Zope 2.8, Five and Interfaces
yuppie wrote: Philipp von Weitershausen wrote: Right. Here's what we could do: 1. Copy Five's interface definitions over to Zope 2.8 (mostly to OFS.interfaces, I guess) where they are added as Zope 2 interfaces I would prefer to reserve the name 'interfaces' for Zope 3 interfaces. So far ZopeTestCase is the only package in Zope 2.8 that uses 'interfaces' for Zope 2 interfaces. Ok. I don't really care that much. 2. Keep Five's (redudant) interface definitions. They can stay at their status quo (status Zope 2.7, that is). 3. Add five:bridge / calls for every interface so that Five's interfaces are automatically kept up-to-date with the Zope 2.8 ones. The bridges would override the ones defined in the module, potentially updating with newer definitions. The only thing that we need to take care of is fallback for Zope 2.7 where the Zope 2 interfaces don't exist yet. Would this work: Instead of modifying Five at all, could we just add zcml files to the Zope 2.8 packages with Zope 2 interfaces and override the interfaces in Five.interfaces? Yes. We could, for example, add another Product to Zope 2.8 (e.g. 'BridgeInterfaces') that contains a configure.zcml file that does this; that way the ZCML file gets automatically picked up by Five. I leave it to you and the others to decide whether to use this approach (add additional ZCML files to Zope 2.8) or whether to modify Five. I guess your suggestion is slightly more elegant. If you want to do this, yuppie, feel free to do it. I would even be ok for this to be done for the 1.0 branch, provided you also add it on the trunk. If I need to change something in Five: Do I need additional checkin rights on codespeak, or will my kupu login work? Your kupu login will work. 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: Zope 3 Developer's Handbook
Stephan Richter wrote: Hello everyone, I just wanted to let you all know that the first book covering Zope 3 hit the shelves yesterday. It is called the Zope 3 Developer's Handbook and was published by Sams' Developer's Library. Link to Sams Web-Site: http://www.samspublishing.com/title/0672326175 Link to amazon.com: http://www.amazon.com/gp/product/product-description/0672326175 There is also an online version at: http://dev.zope.org/Zope3/Zope3Book However, I did not yet have the time to transfer the editions made by Sams back to the online version. This will happen in the next months though. Congratulations, Stephan! I can't wait to hold a copy in my hands! It's quite an accomplishment publishing this book only few months after X3.0 has been released and I know how much pain you must have had rewriting it every three months or so because Z3 got refactored ;). I also know how much work writing a book is, especially when it's about a complex piece of software such as Zope. I'd also like to take this opportunity to let everyone know that a second, complementary book on Z3 written by myself and targeted towards the non-experienced Zope3 developer (such as Zope 2 convertees) is going to be available in about a month (Springer, the publishing company, says around March 10). So, watch out for those Amazon bundles! :) With Jim's sprint oriented ProgrammerTutorial, the developer oriented Developer Handbook and a beginner oriented book -- not to mention excellent source code documentation --, Zope 3 is now unlikely to suffer from a lack of documentation like Zope 2 did before the first Zope book was finally published in 2001. Especially in this difficult time of wanting to migrate sooner or later, having good documentation is the best way of lowering the barrier. Anyway, Stephan, keep up the good work. X3.0 wouldn't be there without you and neither would this tremendous documentation effort. 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: Zope 3 Developer's Handbook
Sorry for the flooding, it seemed that GMane rejected my messages because my computer clock was set month ahead (no idea why) while in fact the messages were posted. 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: status of Zope versus zope?
Martijn Faassen wrote: Jim Fulton wrote: Martijn Faassen wrote: I chose alternative 4 from: http://dev.zope.org/Zope3/RenameTheZopePackage As that seemed to be the most popular, although I personnally prefer 3. Resolving this peacefully is becoming more urgent for me as I'd like to be able to use Five (Zope 3 on Zope 2) on Windows eventually. Is there some workaround? Sure, put zope in a different directory. I don't understand what this means. A different directly on the python path? I would recommend leaving old Zope2 stuff in lib/python and putting all Z3-related stuff in a parallel directory called 'src'. That way you can run a whole Zope3 checkout in parallel to Zope2. Telling Zope2 about the extra python-path shouldn't be a problem through ZConfig (there's a directive). Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Do we need a Packages directory in the new repository
Jim Fulton wrote: Historically, we've had Packages, Products, Packages3 and Products3 directories in the CBS repository. I wonder of we need these going forward. Perhaps we should just have top-level projct directories in the new subversion repository. +1 Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Zope3-dev] Need help with http://dev.zope.org/Subversion
Andreas Kostyrka wrote: On Sun, Apr 25, 2004 at 12:48:30PM -0400, Fred Drake wrote: On Sunday 25 April 2004 12:29 pm, Jim Fulton wrote: cvs co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3 That should be: svn co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3 cvs co http://svn.zope.org/repos/Zope3/trunk Zope3 and this would be: svn co http://svn.zope.org/repos/Zope3/trunk Zope3 Does that mean, that Zope will use svn with cleartext passowords for write access? No. If you look at the URI above, you see that we use svn+ssh for writable checkouts. This is essentially just like the SSH tunelling of CVS. Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: The bleak Future of Zope?!
Jim Fulton wrote: 2. Especially Andreas expressed his worries about the current release policy in Zope 2 and its future regarding maintainance and support. I have to say that I share some of his skepticism regarding Zope 2. I personally have never fully understood ZC's reasons for the release roadmap as it is. I might not see the big picture, but I know I would have done it differently. I've always tried to make that clear in the past. I'm surprised to read this. Could you be more specific about your concerns? I should have said the release roadmap as it WAS. I was very skeptical about the original plans to make Zope3 backward compatible. I am still very skeptical about the ability to add conversion scripts. They would be incredibly tedious painful to write and I personally would rather migrate code manually than trust a script. After all, the paradigms have changed a lot. I see it as realistic as Stephan. There is no sane migration to Zope3 than the one of refactoring code. Now, in order for that to happen, we need the CA in Zope2, so people can start asap. My only criticism has been and still is that the CA hasn't been introduced to Zope2 earlier. Now, I know that a) the CA has been refactored a lot since its invention (and IMO only for the good) and b) there was a lack of resources to do that actual integration. That's why I've never declared anyone guilty for it (which is why you may be surprised by this). It sure would have been nice if Gary had shared his experience with FrankenZope a little earlier. I remember Martijn being quite eager to experiment with it, too. But that's the only constructive criticism I have. Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Rename zope package
Jim Fulton wrote: Philipp von Weitershausen wrote: Why would they switch to Zope 2.8 if not for the component architecture? To stay current? To get MVCC? To get new-style extension classes, and thus access to many modern Python features. Later releases will provide benefits beyond just the Z3 features. But, if they are willing to investigate into new features, new-style extensions classes and all that, a small package rename from Zope to Zope2 should be just as manageable. Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: The bleak Future of Zope?!
Martin, Maik, Andreas, and others, I see two issues being raised in this thread: 1. Maik disagrees with the design philosophy behind Zope3 (the Component Architecture) and the place Zope3 wants to position itself at in the future. As a Zope developer who has spent the last two years both developing *with* Zope2 and developing Zope3 itself, I obviously have a different point of view about the technical part. Whether Zope3 will be success in its market niche is yet to be determined. If you fight, you can win the war; if you give up now, you've already lost the war. Since this is more a philosophical issue, or even a matter of taste, I am not going to argue too much about it. I find the component architecture superior to anything we have seen before and we will soon have proofs that it is capable of industrial strength applications. Most other developers who are involved into development with or of CMF (such as the leading Plone developers) seem to share that point of view; in fact, we all can't hardly wait for Zope3 to hit stable. 2. Especially Andreas expressed his worries about the current release policy in Zope 2 and its future regarding maintainance and support. I have to say that I share some of his skepticism regarding Zope 2. I personally have never fully understood ZC's reasons for the release roadmap as it is. I might not see the big picture, but I know I would have done it differently. I've always tried to make that clear in the past. Coming up with harsh criticism now is not very fair, I think, especially when you're as in involved as Maik or Andreas. Zope 2 development has opened for the community a lot in the past. While people were to extend Zope2 with more or less useful features (seemed to me that it was more than fixing bugs), all the administrative stuff got stuck with ZC. Did anyone from the community ever volunteer helping with the releases or the CVS administration? In this matter, btw, the future painted in Zope3 is brighter: more community involvement, more innovations coming from the community and more administrative tasks taken up by volunteers. Not that I'm not suggesting that more help is needed... Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: More arguments for z (was Re: Zope and zope)
Jim, let's make this telegraph style :) OK, here's another. What about renaming the Zope 3 zope package to z. +1 - It fits with the expansion of Zope: Z Object Publishing Environment. - It's short :) - *At this time* (but after the move to svn), it's not too hard to make a change like this for Zope 3. Backward compatibility is not a big issue. This will change when X3.0 is released, which is why I'm bothering to deal with this now. +1 Other reasons I like z: - Less noise in imports +1 - Echos the circle z +0 (that's a marketing issue ;)) - The packages in z can be used for more than just Zope +2 - Emphasizes the more minimalist nature of Zope 3 relative to Zope 2 +2 Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope and zope
Jim Fulton wrote: The first question is: Is it a problem to have two packages with names differing only in case? I don't see a problem at all; IIRC, we agreed that the backports from Zope3 would live in a 'src' directory, while Zope 2 stuff continues to live in 'lib/python'. No case problem therefore, since they would be in different directories. I haven't gotten as many responses on this as I expected. I'll try to summarize so far: - Chris feels strongly that this is a problem - I've been swayed by Chris' response from neutral to thinking that this is a problem. - Tres seems not to think this is a problem, but I'm not sure. - Fred doesn't seem to think this is a problem. - I can't tell from Robert's and Stephans responses whether they think this is a problem or not. Perhaps we can get more input on whether there's a problem. A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :) -2 The reason why I don't see a big problem from the aesthetic point of view is that the 'Zope' package isn't used much in Zope2 anyway. Most stuff is in top-level packages such as OFS, App, Acquisition, ZPublisher, ZServer etc. I have Zope2 products that don't even import from 'Zope'. So, who would care? Renaming it would just be a hassle and asking for trouble (esp. regarding incompatabilies). I can see why it might be embarrassing having to document two package names that only differ by case. For newbies, it might even be confusing (though again, who ever gets in touch with lib/python/Zope?). But so is Zope2's codebase already. Most code is icky and naming conventions simply don't exist. Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: CVS: Zope3/src/zope/tal - talparser.py:1.6
Gintautas Miliauskas wrote:
Update of /cvs-repository/Zope3/src/zope/tal
In directory cvs.zope.org:/tmp/cvs-serv27951/src/zope/tal
Modified Files:
talparser.py
Log Message:
Removed an assertion which disallows usage of Zope3 i18n in XML markup.
Added a few test cases which run the new code path.
=== Zope3/src/zope/tal/talparser.py 1.5 = 1.6 ===
--- Zope3/src/zope/tal/talparser.py:1.5 Fri Mar 19 16:42:04 2004
+++ Zope3/src/zope/tal/talparser.py Wed Apr 7 11:13:00 2004
@@ -81,7 +81,6 @@
taldict[keybase] = value
item = item + (tal,)
elif ns == 'i18n':
-assert 0, dealing with i18n: + `(keybase, value)`
i18ndict[keybase] = value
item = item + ('i18n',)
fixedattrlist.append(item)
Hello,
I would like to backport this patch (including tests) to Zope 2, since I
need to i18n XML generated by ZPTs.
Any objections?
Philipp
___
Zope-Dev maillist - [EMAIL PROTECTED]
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: Problem with Zope 2.7.0-b1
Jean Baltus wrote: Hi all, The problem I describe here does NOT appear with Zope 2.6.1, nor Zope 2.6.2b4, only with Zope 2.7. I installed Zope 2.7 with CMF 1.4, Plone 1.1alpha2 and TranslationService 0.4. When I create a Plone site (called dice here) Ive got the following error: ... * Module TAL.TALInterpreter, line 562, in do_insertTranslation The behavior is the same with Linux and Windows platform. If you remove translation service, the error disappears (but it used to work with older Zope version thats why I think the problem is in Zope 2.7). Indeed, the ZPT spec about i18n:attributes has changed in a incompatible way and Zope 2.7 is only implementing the new spec which - in my opinion - is unacceptable. I am currently trying to resolve the issue and expect a fix soon. Stay tuned. Best regards, Phil ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: CVS: Zope/lib/python/TAL - TALGenerator.py:1.65
Chris McDonough wrote: Update of /cvs-repository/Zope/lib/python/TAL In directory cvs.zope.org:/tmp/cvs-serv15492/lib/python/TAL Modified Files: TALGenerator.py Log Message: Merge TAL i18n fixes which break CMF to HEAD from 2.7 branch. The agreement Jim was basically that this backward compatability will only go in 2.7, so that 2.8 will be fully compatible with the spec, however break backward compatability. What now? Phil ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: TALES idea: tuple unpacking
Richard Jones wrote: During the Melbourne Zope3 Sprint, someone ran up against a situation where they'd have liked to have TALES perform a tuple unpacking like Python can. I've just run into a similar situation :) Say a method listFilesByUser returns a list of (user, [files]) it'd be nice to be able to:: tal:repeat=user,files here/listFilesByUser or similar. Currently we would have to use a python: expression to manually unpack the tuple. Kinda yucky. I agree that it is 'yucky', but I have to disagree with your proposed solution. I would rather suggest making TALES aware of integer indexes for sequences. Example:: tal:block repeat=user_files here/listFilesByUser User: tal:dummy replace=user_files/0 / File: tal:dummy replace=user_files/1 / /tal:block Regards, Phil ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: TALES idea: tuple unpacking
Shane Hathaway wrote: Here's the way I'd like to spell it: div tal:repeat=user_files here/listFilesByUser User: span tal:replace=user_files/int:0 / File: span tal:replace=user_files/int:1 / /div +1 We've come up with a number of generally useful prefixes, BTW. Off the top of my head: call: -- Call a named method int:-- Look up an item by index format: -- Perform simple formatting operations like format:money zope: -- Access a big Zope API +1 It sure would be nice to have these prefixes, both in Zope 2 and Zope 3. AFAIK, Jim wants this for Zope3 for some time now. The idea is to implement this with named adapters. here/some_object/zope:name would make TALES look up the 'zope' adapter (something that implements zope.app.interfaces.talesapi.IZopeTalesAPI) and get its name attribute/call its name() method. It would really be a two-liner to implement something like an 'int' or 'call' adapter. Other named adapters like 'dc' that adapts an object to a Dublin Core interface would be nice to have as well. A lot of that is in place already, fortunately. The question remains how to implement this in Zope2 as we don't have adapters there. Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: TALES idea: tuple unpacking
Evan Simpson wrote: Hmmm. I hadn't thought of that before, but I've certainly wanted to tell the path traverser whether to use attribute, index, or key access on several occasions (using 'items' as a dictionary key bites me regularly). I can imagine the pain. Explicit is better than implicit. This suggests the following prefixes: 'key:' -- use item access with the prefixed string. 'index:' -- use item access with the prefixed integer. 'attr:' -- use attribute access with the prefixed string. +1 There's an alternative, longer syntax that would be more consistent with the adapter concept from Zope 3. Given that prefixes are meant to be namespaces, 'key', 'index', and 'attr' should be elements of a namespace (perhaps 'by' or 'as' to keep it reasonably short) rather than prefixes themselves. In this case, we would have the path expression options/a_mapping/by:key/items/by:index/0. *ugh*. Too long. You'd keep adding thousands of elements to your TALES expression... Note that this form has the advantage of allowing a_list/by:index/?i. Why wouldn't that be possible with a_list/index:?i? Phil ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Renaming a product
Clemens Robbenhaar wrote: The actual work is the transformation of instances of class A.Foo to class B.Foo; to be on the safe side one would have to copy over all attributes manually. If You want to try a fast and dirty solution, You could try to write the new class into the '__class__' attribute of the instance of the old class, making it an instance of the new class, but I do not know it this really works. Somebody correct me please, if I'm wrong, but 1. tinkering with __class__ is the only way to do this. 2. you can not tinker with __class__ of an ExtensionClass, i.e. all Persistent objects. So, it is not doable, IIRC. Phil ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Dynamically add an external method at startup
Hi, def addExternalMethod(self, id, title, module, function, REQUEST=None): Add an external method to a folder id=str(id) title=str(title) module=str(module) function=str(function) i=ExternalMethod(id,title,module,function) #self._setObject(id,i) I don't get errors at start up, and of course my product isn't registered, but can anyone tell me what self wants to be in addExternalMethod and how I could get there from initialize(context)? self wants to be the folder where you want to add the ExternalMethod. ObjectManagers, thus also Folders, have a method _setObject that allow you to add objects to them. Phil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Error message traceback
Hi there, how do I turn off this annoying traceback that is always printed out when an error occurrs? -- Philipp von Weitershausen [ *pronounce: "fun Viters-houzen" ] Web http://www.philikon.de/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Editing DTML Documents
Hi there, Is there an efficient way to use an external editor to edit DTML Documents? Some people in my homepage group are tired of the ZMI and I can understand them, especially because of a lack of syntax highlighting. There is the possibility of copy'n'paste and upload again, but that's ugly. I also read that development on the Mozilla-based management tool is not continued. (That's sad, BTW...) Could I use WebDAV (don't have any experience with it) to retrieve and save the DTML source? If so, is there a good HTML source code editor (don't want WYSIWYG!) for Windows or Linux supporting WebDAV? Any suggestions welcome! Phil -- Philipp von Weitershausen [ *pronounce: "fun Viters-houzen" ] http://www.philikon.de/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
