January 2007 - Zope-Dev

ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Hanno Schlichting 15 Jan '07

15 Jan '07

Hi. (I already send this mail through gmane but it didn't show up on the lists for half a day. So it might show up twice later on, sorry.) Spawning of a discussion on plone-devel (http://thread.gmane.org/gmane.comp.web.zope.plone.devel/13865/focus=13865) about how to use eggs and their features like entrypoints in our current development environments, we discussed some of the available options. As I think this is a common problem for all Zope2 developers I'll post this to zope-devel as well. In order to get a better understanding of how one of the possible solutions called zc.buildout works, I started to write all those recipes one would need to set up a full development environment for Plone 3.0. Quite frankly most of the work was already done by Jim and I only needed to adjust some of his Zope3 specific recipes ;) A full Plone 3.0 environment includes (should be similar for other projects): - Checking out the Zope 2.10 branch and compiling the C extensions - Creating a Zope instance - Checking out one or many SVN bundles containing a multitude of Products and moving these into the instance - Checking out a product from CVS and moving it into the instance (hopefully you don't need to do that anymore :) - Installing some external Python packages (elementtree, PIL, py-openid, ...) and making those available in the Zope instance - Somehow putting 19 Python packages in development mode into the instance (these are the ones we have written ourselves) I have put those recipes that where necessary to automate all of these steps into the ploneout package (https://svn.plone.org/svn/plone/ploneout/trunk) but intend to move them to svn.zope.org as soon as I have commit rights and should people be interested in them. The four recipes that I have written, are able to check-out Zope2 and compile it inplace, create a Zope2 instance, check out a bundle (any folder really) from either SVN or CVS and finally enable a folder as a working environment (http://www.python.org/pypi/workingenv.py) Among the more useful features are: - All recipes support both the global as well as a part specific offline option, so you can tell each checkout separately, that it should not do anything by itself after the first checkout. This can cut down the time needed to update the buildout quite enormously. - The Zope2 instance recipe takes a product-set option. You can give it a list of bundles and it will symlink all folders included in each bundle into the instance. - The Zope2 instance recipe also supports the zcml option known from it's Zope3 counterpart, so you can create ZCML slugs automatically. - The workingenv recipe takes any folder (usually a Zope2 instance) and turns it into a workingenv, supporting all the command line options workingenv itself support. Among these is also the requirements option that lets you specify a text file (url or local file) which includes dependencies to be installed into the workingenv. - And as another special option the workingenv recipe supports an additional develop-set option which like the Zope instance product-set option takes a bundle (any local folder really) and calls setup.py develop on any package it finds in there. Usually this installs all those packages into INSTANCE_HOME/lib/python (the workingenv) in development mode. If you combine all of those recipes (like it's done in the ploneout/buildout.cfg) you get a working Zope2 instance and have various ways of installing both products and packages into it. Currently you won't get a running Plone 3.0 instance as not all of the required newly written Python packages are setuptools enabled yet. What's missing now is a more seamless integration of the packages or eggs installed into the workingenv and those installed in the global buildout itself. Secondly in order to be productive one would need some more nice scripts in the global buildout/bin that would allow to start the Zope instance, run tests from any development egg, Product or Zope itself reliably, a recipe to automatically populate the ZODB with some initial content like a Plone site... and the usual Windows support that isn't yet there but could be easily added if people show any interest in those recipes. Currently this was only an exercise to support development environments, for deployment you would want to use released versions which would need some new recipes. As this is my first attempt to use zc.buildout I might have made some obvious mistakes not recognizing it's potential or working against its design. Please tell me about those mistakes :) My current conclusion for using zc.buildout is that it makes setting up a complete environment from scratch a lot easier and should help developers that are not that advanced yet or are not developers at all. Think of the first day at a sprint for example, where you spent time helping people to get a running system or doing that with your designers. For advanced developers it constrains them in a way they might not find acceptable - we all have our different ways of managing our projects right now. If you use buildout for a complex project you can either use it or not, you cannot really use only parts of it. Comments and suggestions are welcome as always ;) Hanno

1 0

[Trunk] some tests will fail
by Andreas Jung 14 Jan '07

14 Jan '07

I added/extended some tests that will fail because of errors in Zope. One failure is related to the FTP acquisition bug (#2261). Two other failures are related to rendering ZPTs with content_type text/xml. -aj

2 1

Zope Tests: 6 OK, 1 Failed
by Zope Tests Summarizer 14 Jan '07

14 Jan '07

Summary of messages to the zope-tests list. Period Sat Jan 13 12:00:00 2007 UTC to Sun Jan 14 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Test failures ------------- Subject: FAILED (failures=1, errors=2) : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Jan 13 21:19:29 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007040.html Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Sat Jan 13 21:10:28 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007034.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sat Jan 13 21:11:59 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007035.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sat Jan 13 21:13:29 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007036.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sat Jan 13 21:14:59 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007037.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Jan 13 21:16:29 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007038.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Jan 13 21:17:59 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007039.html

1 0

Problems checking out zope.interface
by Grig Gheorghiu 14 Jan '07

14 Jan '07

I'm trying to check out zope.interface for one of the tests I'm running for Twisted in the Pybots project. I've been getting an error lately: [twistbot@concord tmp]$ svn co svn://svn.zope.org/repos/main/zope.interface/trunk zope.interface A zope.interface/buildout.cfg A zope.interface/CHANGES.txt A zope.interface/setup.py A zope.interface/src A zope.interface/src/zope A zope.interface/src/zope/__init__.py A zope.interface/README.txt U zope.interface Fetching external item into 'zope.interface/src/zope/interface' Permission denied (publickey,keyboard-interactive). svn: Connection closed unexpectedly Any ideas why this is happening? Grig

2 1

Error running ZPublisher tests
by Andreas Jung 14 Jan '07

14 Jan '07

Running the ZPublisher tests (on the trunk) alone results in the following error. However the tests works when running all unittests. Bug or feature? Andreas ------------ ajung@galactica:~/sandboxes/Zope/Zope> bin/zopectl test -s ZPublisher Running tests via: /opt/python-2.4.3/bin/python /develop/sandboxes/Zope/Zope/bin/test.py -v --config-file /develop/sandboxes/Zope/Zope/etc/zope.conf -s ZPublisher Parsing /develop/sandboxes/Zope/Zope/etc/zope.conf Running tests at level 1 Running unit tests: Running: .....................................2007-01-14 11:26:30 ERROR ZPublisher '__before_publishing_traverse__' call <ZPublisher.tests.testBeforeTraverse.BrokenHook instance at 0x2ae2fa224e18> failed. Traceback (most recent call last): File "/develop/sandboxes/Zope/Zope/lib/python/ZPublisher/BeforeTraverse.py", line 105, in __call__ cob(container, request) File "/develop/sandboxes/Zope/Zope/lib/python/ZPublisher/tests/testBeforeTraverse.py", line 30, in __call__ raise TypeError, self.__class__.__name__ TypeError: BrokenHook 2007-01-14 11:26:30 ERROR ZPublisher BeforeTraverse: Error while invoking hook: "broken_callable" Traceback (most recent call last): File "/develop/sandboxes/Zope/Zope/lib/python/ZPublisher/BeforeTraverse.py", line 145, in __call__ meth(*(container, request, None)[:args]) File "/develop/sandboxes/Zope/Zope/lib/python/ZPublisher/tests/testBeforeTraverse.py", line 30, in __call__ raise TypeError, self.__class__.__name__ TypeError: BrokenHook

2 1

Zope Tests: 6 OK, 1 Failed
by Zope Tests Summarizer 13 Jan '07

13 Jan '07

Summary of messages to the zope-tests list. Period Fri Jan 12 12:00:00 2007 UTC to Sat Jan 13 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Test failures ------------- Subject: FAILED (failures=1) : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Jan 12 21:17:25 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007033.html Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Fri Jan 12 21:08:25 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007027.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Fri Jan 12 21:09:55 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007028.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Fri Jan 12 21:11:25 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007029.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Fri Jan 12 21:12:55 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007030.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Jan 12 21:14:25 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007031.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Jan 12 21:15:55 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007032.html

1 0

Re: [Z3d] 747/ 2 Comment "zope.app.interface PersistentInterfaceClass dependents broken"
by Ross Patterson 12 Jan '07

12 Jan '07

I've submitted a patch for zope.app.interface.PersistentInterfaceClass and it looks like I could use the approach of zodbcode ModuleManagers and zope.app.interface.PersistentInterfaceClass instances for what I need. Over the course of this work, however, I noticed ZODB.persistentclass.PersistentMetaClass. Does anyone have any sense of how one might decide to use persistent modules versus PersistentMetaClass? Which cases are appropriate for which approach? Is either body of code more of less active/up-to-date/well-maintained than the other? My specific case is that I want to allow site administrators to create new marker interfaces to be used to mark content and to register adapters for.' Ross "Collector: Zope 3 ..." <jim(a)zope.com> writes: > Issue #747 Update (Comment) "zope.app.interface PersistentInterfaceClass dependents broken" > Status Pending, core/bug+solution medium > To followup, visit: > http://www.zope.org/Collectors/Zope3-dev/747 > > ============================================================== > = Comment - Entry #2 by rossp on Jan 12, 2007 4:46 pm > > > Uploaded: "persistent-interfaces-fix.diff" > - http://www.zope.org/Collectors/Zope3-dev/747/persistent-interfaces-fix.diff… > a fix for all but the zope.interface.interface.InterfaceClass provides declaration weak reference bug > ________________________________________ > = Request - Entry #1 by rossp on Jan 12, 2007 4:44 pm > > > Uploaded: "persistent-interfaces-tests.diff" > - http://www.zope.org/Collectors/Zope3-dev/747/persistent-interfaces-tests.di… > zope.app.interface.PersistentInterfaceClass uses a PersistentDict for > the dependents attribute instead of the WeakKeyDictionary used in > zope.interface.interface.InterfaceClass. There are a number of bugs > associated with this approach not exposed in any tests. Attached is a > diff to the tests of zope.app.interface and zope.app.component to > expose these bugs. > > Firstly, if IFoo is a zope.app.interface.PersistentInterfaceClass > instance and zope.interface.directlyProvides(foo, IFoo), the > declaraion can't be verified from a different ZODB connection with > IFoo.providedBy(foo) due to the following. When the ZODB is trying to > unpickle the dependents attribute of IFoo, it procedes down the > serialization of IFoo to the ProvidesClass instance representing the > declaration. It begins reconstituting the ProvidesClass instance, > which calls IFoo.subscribe(provides) which accesses the dependents > attribute of IFoo. Since the ProvidesClass instance isn't persistent, > it has no oid the ZODB circular reference check doesn't catch this > circle. As a result the fix is to make sure that the declarations > instances in the dependents attribute are themselves persistent. > > Also attached is a diff to zope.app.interface that replaces > PersistentInterfaceClass.dependents with a custom dict that converts > non-persistent declarations being added to the dependents attribute > into persistent versions of the same. > > This fixes the problem but is not optimal because there are then two > instances for the same declaration, one in the ProvidesClass instance > stored in the object's __provides__ attribute and the other in the > dependents attribute of the PersistentInterfaceClass. > > It seems like the more appropriate solution would be to check for > PersistentInterfaceClass instances in > zope.interface.declarations.directlyProvides and use the persistent > declaration classes for those declaraions. Since > PersistentInterfaceClass is in zope.app.interface and zope.interface, > I wasn't sure which was the lesser of the two evils, so I restrained > my changes to zope.app. What might be a better solution? Give me > some feedback and I'll change the implementation. > > There's another problem with the > zope.app.interface.PersistentInterfaceClass.dependents attribute. > zope.interface.InterfaceClass.dependents is a WeakKeyDictionary so > that declarations don't keep objects from being freed if the object is > removed. By using a PersistentDict for dependents, the declarations > can keep an object from being freed from memory and/or the ZODB when > the object is removed. > > My first patch also includes tests for this bug. These tests seem to > have exposed another unrelated bug. An instance of a class that > subclasses persistent.Persistent is declared that it > zope.interface.directlyProvides a zope.interface.InterfaceClass > instance and then the persistent object is added to the ZODB and > committed. Then if the persistent instance is deleted from the ZODB, > the transaction is committed, and the ZODB is packed, and gc.collect > is run, the ProvidesClass instance in the InterfaceClass instance > still remains. It does not, however, remain if the persistent > interface was never added to the ZODB. > > I'm not sure if this represents a potential memory leak or not. What > confuses me is that it all behaves properly unless the persistent > instance is added to the ZODB. I noted the comment about weak > referrences being added to the ZODB optomistically in ZODB.serialize. > Could that be it? Unfortunately, my second patch doesn't include a > fix for this. I'd be happy to investigate this further if given a > little direction. > ==============================================================

1 0

Zope Sprints at PyCon
by Jim Fulton 12 Jan '07

12 Jan '07

There will be a couple of Zope sprints at PyCon this year: http://us.pycon.org/TX2007/Sprints Benji York and I will be there on Monday and Tuesday, February 26 and 27. I'd like to work on Zope3 eggification with a goal of being able to assemble the Zope 3 application included in Zope 3 releases from a collection of eggs. This will be part of the Zope 3.4 sprint, http://us.pycon.org/TX2007/ Zope34Sprint. I hope t see some more folks there. Maybe there should be a Zope 2 sprint. BTW, PyCon Early Bird Registration ends soon! Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 0

[Warning] Zope 3 component architecture (CA) not reliably usable for registrations from Python
by Dieter Maurer 12 Jan '07

12 Jan '07

I tried to use Zope3 events to get informed when requests start and end. One of our modules (the interface module to "jpype") requires such a notification for reliable work. Therefore, it tried to register the corresponding subscriptions on import of this module. Unfortunately, this works very unreliably -- for the following reasons: The CA performs by itself only extremely minimal initialization. Especially, it does not register the "Adapters" service, necessary for the registration of event subscriptions. The full CA initialization is only performed quite late, in the call to "Products.Five.initialize". Event notification registration attempts before this time will fail (with a "ComponentLookupError: 'Adapters'"), those performed after this time will succeed. The "Five" initialization is stupid enough that it will fail when the service registration for 'Adapters' has already been performed. At the current state, event notifications can reliably only be defined via ZCML. This is unfortunate for our use case where the registration should be bound to the import of a given module. -- Dieter

6 15

Zope Tests: 7 OK
by Zope Tests Summarizer 12 Jan '07

12 Jan '07

Summary of messages to the zope-tests list. Period Thu Jan 11 12:00:00 2007 UTC to Fri Jan 12 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Thu Jan 11 21:09:40 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007020.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Jan 11 21:11:11 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007021.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Jan 11 21:12:41 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007022.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Jan 11 21:14:11 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007023.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 11 21:15:46 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007024.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 11 21:17:16 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007025.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 11 21:18:46 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007026.html

1 0