November 2007 - Zope-Dev

A book about Zope Component Architecture
by Baiju M 15 Nov '07

15 Nov '07

Hi all, I started writing a book about Zope Component Architecture. http://www.muthukadan.net/docs/zca.html http://www.muthukadan.net/docs/zca.pdf If you have any suggestions/comments please send it to me. The book's source is hosted here: https://edge.launchpad.net/zcadoc BTW, I have used CSS available in Zope 3 source and LaTeX style available in Grok project's repository. Regards, Baiju M

3 3

conflict error
by peter.koppatz＠sudile.com 15 Nov '07

15 Nov '07

Hello, how can the error be corrected? ./bin/easy_install -U zcontact Searching for zcontact Reading http://pypi.python.org/simple/zcontact/ Reading http://launchpad.net/zcontact Best match: zcontact 0.1.0a9 Processing zcontact-0.1.0a9-py2.4.egg zcontact 0.1.0a9 is already the active version in easy-install.pth Using /home/peter/p007-zcontact-demo/lib/python2.4/site-packages/zcontact-0.1.0a9-py2.4.egg Reading http://download.zope.org/zope3.4 Processing dependencies for zcontact error: Installed distribution zope.traversing 3.4.0 conflicts with requirement zope.traversing>=3.5.0a1.dev-r78730 Peter

3 3

Egg install bot results
by Chris McDonough 15 Nov '07

15 Nov '07

I've created a bot process (see http://svn.repoze.org/playground/trunk/chris/zopesvnchecker/checker.py) that: - checks out the "trunk" subdir of each top-level directory in svn.zope.org - if the resulting directory does not have a "setup.py", we skip the directory - if the resulting directory does have a setup.py, we create a temporary virtualenv with setuptools installed and run the virtualenv's bin/python passing it "setup.py install". - We capture the results of the install, and print a summary. The "summary" results are at http://www.plope.com/static/misc/checker_results.txt . The "details" pickle generated by the script is at http://www.plope.com/static/misc/results.pickle . My analysis of the results are these: - A version conflict exists in a low-level dependency between a requirement for zope.traversing 3.4.0 and a requirement for zope.traversing>=3.5.0a1.dev-r78730 when installing many zope.* eggs using "setup.py install" (and easy_install), making it impractical for non-Zope people to actually install most of the interesting and released zope.* modules. This conflict needs to get fixed. Additionally, some modules (like zope.pagetemplate) should not fail with this dependency error in the first place; instead their dependencies need to become less conservative. - The only 10 packages (out of 80) in the zope.app namespace can be easy_installed. All the others fail with the above dependency error. Suggestions: - Find and fix the zope.traversing easy_install conflict. I'll try to debug this. - Institute a policy that all distributions that are released to the cheeseshop should be installable via "easy_install". IMO, if they are not installable this way, they should not be released to the cheeseshop, given the larger Python community's expectations. - Figure out why buildout can (apparently) qsuccesfully install dependencies of currently failing zope.* eggs while easy_install can't. I probably won't be able to do this. - An automated test should ensure that easy_install does something reasonable with the latest release of each distribution. If the test fails, a new release should be made, or the dependency bug tracked down and fixed. My checker script could be made to do this, and I'd provide the work if someone told me which distributions to test, and how to maintain the list of distributions to test over time. - Ditch the idea of releasing separate distributions for each package in zope.app. The individual eggs typically can't be used outside of a zope appserver installation (and if they can, they probably shouldn't be in "zope.app", they should be in "zope" or they should be their own top-level package), and the "namespaciness" of zope.app is suspect when it's unlikely that anyone who is not a Zope committer will release a distribution which makes use of that namespace package. Their current overgranularity makes distributing them as separate eggs and releasing them to the cheeseshop a form of "cheeseshop pollution", especially given that so few of them can actually currently be installed using easy_install or "setup.py install". If cheeseshop is going to continue to be used as the index, I'd suggest creating a zope.app top-level svn module with a single setup.py in containing all the packages that are meant to go into zope.app. Version the resulting "zope.app" distribution as necessary instead of versioning many more granular "zope.app.*" distros. It's OK if some people don't use some of the functionality in the resulting egg, just toss everything in. There is precedent here in the Paste distribution. It has many submodules and does many things, but it comes in the form of a single egg. Yes, you lose the ability to make a bugfix in one subpackage and release it, but IIRC the intent is to trim zope.app down anyway, pushing libraryish things out to top-level or zope.* packages. Issues: - Who's in charge? Whomever you might be, to what extent do you agree/disagree with the above suggestions? If you agree with any, how can I help fix things? - I'm unsure how anybody is able to install Zope 3 right now using eggs, unless there's some fundamental difference in the way easy_install resolves dependencies vs. buildout. I have not looked at how Stephan's KGS works yet, though, so I'm sure I'm just missing some magic. - We should consider fixing setuptools install to detect conflicts before attempting to install anything. The current regime of "find conflicts halfway through an install" is IMO untenable in the long term for using eggs as a distribution mechanism. This may mean a very invasive change to both the package index and the client software, though.

4 13

Zope Tests: 5 OK
by Zope Tests Summarizer 14 Nov '07

14 Nov '07

Summary of messages to the zope-tests list. Period Tue Nov 13 13:00:00 2007 UTC to Wed Nov 14 13:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Tue Nov 13 20:55:02 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008641.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Tue Nov 13 20:56:33 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008642.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Tue Nov 13 20:58:04 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008643.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Tue Nov 13 20:59:34 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008644.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Tue Nov 13 21:01:05 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008645.html

1 0

zope.publisher returns 200 Ok instead of 200 OK
by Martijn Faassen 13 Nov '07

13 Nov '07

Hi there, In zope.publisher.http, the status string for 200 is defined to be 'Ok', instead of 'OK', which is in the HTTP spec. Now status messages may, according to the spec, be replaced by 'local equivalents' without affecting the protocol, and the status messages in the spec are just examples. Still, it's a difference without a good reason. Changing this to 'OK' has some impact: particularly tests which verify the status string (which I'm currently writing) will break. Then again, thats' an easy fix. What do people think? Should this be fixed? Regarsd, Martijn

2 2

Zope Tests: 4 OK, 1 Failed
by Zope Tests Summarizer 13 Nov '07

13 Nov '07

Summary of messages to the zope-tests list. Period Mon Nov 12 13:00:00 2007 UTC to Tue Nov 13 13:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Test failures ------------- Subject: FAILED (errors=1) : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Nov 12 20:53:48 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008637.html Tests passed OK --------------- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Nov 12 20:52:18 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008636.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Nov 12 20:55:19 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008638.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Nov 12 20:56:49 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008639.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Nov 12 20:58:19 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008640.html

1 0

Trying to summarize the requirements for the package version story
by Lennart Regebro 12 Nov '07

12 Nov '07

I'm trying to get my head around the package versioning requirements. It seems to me that we have the following requirements: 1. We need to be able to in a buildout say "I want to use Zope version 3.4, thanks", and the buildout should then download the latest versions of the relevant Zope packages that make up Zope 3.4. 1a. If bugfixes are released bin/buildout will install and upgrade the bugfixes. 1b. If a version of zope.something is released that is NOT compatible with 3.4, but compatible with 3.5, that version will NOT be downloaded. 2. We need to be able to in a buildout say "I want to use Zope version 3.4.5, thanks", and the buildout should then download that the set of eggs that is Version 3.4.5. 2a. If bugfixes are released for Zope 3.4 these will NOT be downloaded. (2b. Although if there is a way to make security fixes to be automatically downloaded, that would be neat) 3. We need to be able to in a buildout say "I want to use Grok 1.2" and Grok 1.2 will automatically depend on a specific version of Zope, say 3.4.5. I.e., we want to be able to "extend" Known Good Sets. 4. We want to in the buildout be able to specifically override a version of a package, I say that we want to use zope.whatever 3.5.6, although it is not an "approved part" of the Zope version we have specified. 5. We want an egg that the buildout depends on to be able to override the version of a package. I.e, if the buildout installs. zc.coolpackage, and that requires zope.something 1.3.2, although the Zope 3.4 KGS specifies 1.2.3, 1.2.3 should be used. 1 can not be solved by having version information in the packages, because I think the list of versions, AKA the "Known Good Set" is going to have to be updated more or less manually with releases, right? Because you can't just take the last version of everything, because sooner or later somebody releases somthing that breaks it. And updating the list would require you to re-release a package, which is bad. 2a can be solved by version information in packages, 2b can not. 3 needs an extension mechanism. 4 and 5 are version conflict resolution problems, which already exists, right?

1 0

Zope Tests: 5 OK
by Zope Tests Summarizer 12 Nov '07

12 Nov '07

Summary of messages to the zope-tests list. Period Sun Nov 11 13:00:00 2007 UTC to Mon Nov 12 13:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Nov 11 20:52:22 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008631.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Nov 11 20:53:53 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008632.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Nov 11 20:55:23 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008633.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Nov 11 20:56:53 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008634.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Nov 11 20:58:24 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008635.html

1 0

Duplicate directive registration allowed
by Malthe Borch 12 Nov '07

12 Nov '07

In zope/configuration/config.py:register it seems that it isn't being asserted that no previous registration of a directive with the same name has happened. This might be desirable (not sure why) and currently happens for these directives: ('http://namespaces.zope.org/meta', u'directive') ('http://namespaces.zope.org/meta', u'groupingDirective') ('http://namespaces.zope.org/meta', u'complexDirective') ('http://namespaces.zope.org/zope', u'securityPolicy') This is on Zope 2.10. So for instance, if Five registers the <browser:viewlet> then there's nothing to prevent another package from including zope.viewlet's meta.zcml which will then override that directive, breaking viewlet support on Zope 2.10. \malthe

2 2

buildbot failure in Zope trunk 2.4 Windows 2000 zc-bbwin6
by buildbot＠zope.com 11 Nov '07

11 Nov '07

The Buildbot has detected a failed build of Zope trunk 2.4 Windows 2000 zc-bbwin6. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 3425 Blamelist: adamg,ctheune,gregweb,nikhil_n,oestermeier,philikon,srichter,torsti BUILD FAILED: failed test sincerely, -The Buildbot

1 0