November 2007 - Zope-Dev

Fixing zope.i18n dependencies
by Chris McDonough 16 Nov '07

16 Nov '07

Currently zope.i18n has an inappropriate set of installation-time dependencies: RestrictedPython-3.4.2-py2.4.egg ZConfig-2.5-py2.4.egg ZODB3-3.8.0b4-py2.4-macosx-10.3-i386.egg docutils-0.4-py2.4.egg pytz-2007g-py2.4.egg zdaemon-2.0.1-py2.4.egg zodbcode-3.4.0-py2.4.egg zope.annotation-3.4.0-py2.4.egg zope.app.applicationcontrol-3.4.1-py2.4.egg zope.app.appsetup-3.4.1-py2.4.egg zope.app.authentication-3.4.1-py2.4.egg zope.app.basicskin-3.4.0-py2.4.egg zope.app.broken-3.4.0-py2.4.egg zope.app.component-3.4.1-py2.4.egg zope.app.container-3.5.3-py2.4-macosx-10.3-i386.egg zope.app.content-3.4.0-py2.4.egg zope.app.debug-3.4.0-py2.4.egg zope.app.dependable-3.4.0-py2.4.egg zope.app.error-3.5.1-py2.4.egg zope.app.exception-3.4.1-py2.4.egg zope.app.folder-3.4.0-py2.4.egg zope.app.form-3.4.1-py2.4.egg zope.app.generations-3.4.1-py2.4.egg zope.app.http-3.4.1-py2.4.egg zope.app.i18n-3.4.4-py2.4.egg zope.app.interface-3.4.0-py2.4.egg zope.app.locales-3.4.0-py2.4.egg zope.app.pagetemplate-3.4.0-py2.4.egg zope.app.principalannotation-3.4.0-py2.4.egg zope.app.publication-3.4.3-py2.4.egg zope.app.publisher-3.4.1-py2.4.egg zope.app.renderer-3.4.0-py2.4.egg zope.app.rotterdam-3.4.1-py2.4.egg zope.app.schema-3.4.0-py2.4.egg zope.app.security-3.4.0-py2.4.egg zope.app.session-3.5.1-py2.4.egg zope.app.testing-3.4.1-py2.4.egg zope.app.wsgi-3.4.0-py2.4.egg zope.app.zapi-3.4.0-py2.4.egg zope.app.zcmlfiles-3.4.3-py2.4.egg zope.app.zopeappgenerations-3.4.0-py2.4.egg zope.cachedescriptors-3.4.0-py2.4.egg zope.component-3.4.0-py2.4.egg zope.configuration-3.4.0-py2.4.egg zope.contenttype-3.4.0-py2.4.egg zope.copypastemove-3.4.0-py2.4.egg zope.datetime-3.4.0-py2.4.egg zope.deferredimport-3.4.0-py2.4.egg zope.deprecation-3.4.0-py2.4.egg zope.dottedname-3.4.2-py2.4.egg zope.dublincore-3.4.0-py2.4.egg zope.error-3.5.1-py2.4.egg zope.event-3.4.0-py2.4.egg zope.exceptions-3.4.0-py2.4.egg zope.filerepresentation-3.4.0-py2.4.egg zope.formlib-3.4.0-py2.4.egg zope.hookable-3.4.0-py2.4-macosx-10.3-i386.egg zope.i18nmessageid-3.4.3-py2.4-macosx-10.3-i386.egg zope.interface-3.4.1-py2.4-macosx-10.3-i386.egg zope.lifecycleevent-3.4.0-py2.4.egg zope.location-3.4.0-py2.4.egg zope.minmax-1.1.0-py2.4.egg zope.modulealias-3.4.0-py2.4.egg zope.pagetemplate-3.4.0-py2.4.egg zope.proxy-3.4.0-py2.4-macosx-10.3-i386.egg zope.publisher-3.4.1-py2.4.egg zope.schema-3.4.0-py2.4.egg zope.security-3.4.0-py2.4-macosx-10.3-i386.egg zope.session-3.4.1-py2.4.egg zope.size-3.4.0-py2.4.egg zope.structuredtext-3.4.0-py2.4.egg zope.tal-3.4.1-py2.4.egg zope.tales-3.4.0-py2.4.egg zope.testing-3.5.1-py2.4.egg zope.thread-3.4-py2.4.egg zope.traversing-3.4.0-py2.4.egg I suggest that it's actual runtime set of dependencies are these (or fewer): pytz-2007g-py2.4.egg zope.component-3.4.0-py2.4.egg zope.deferredimport-3.4.0-py2.4.egg zope.deprecation-3.4.0-py2.4.egg zope.event-3.4.0-py2.4.egg zope.i18nmessageid-3.4.3-py2.4-macosx-10.3-i386.egg zope.interface-3.4.1-py2.4-macosx-10.3-i386.egg zope.proxy-3.4.0-py2.4-macosx-10.3-i386.egg If we can come to an agreement that this is the "right" set of runtime dependencies (as opposed to testing dependencies, which add to this set), we'd be in good shape. It means that we'd need to forego the idea that installing zope.i18n by itself would get us any ZCML support. Alternately, we talked on IRC about splitting this package up into one that had no ZCML and one that had ZCML and dependencies on the ZCML processing machinery, but I suggest that that's a "Zope 3.5" sort of thing, and we should try to fix these dependencies in a 3.4 version bump without splitting packages via paring down "install_requires" vs. "tests_require". - C

1 0

zope.tal 3.4.1 released
by Chris McDonough 16 Nov '07

16 Nov '07

I released zope.tal 3.4.1 to the cheeseshop a few minutes ago. The changes were these: - Removed unnecessary ``dummyengine`` dependency on zope.i18n to simplify distribution. The ``dummyengine.DummyTranslationDomain`` class no longer implements ``zope.i18n.interfaces.ITranslationDomain`` as a result. Installing zope.tal with easy_install or buildout no longer pulls in many unrelated distributions. - Support ability to run tests using "setup.py test". - Stop pinning (no longer required) zope.traversing and zope.app.publisher versions in buildout.cfg. The effect of this change is that instead of installing ~78 eggs when you do "bin/easy_install zope.pagetemplate", you now only get these: zope.i18nmessageid-3.4.3-py2.4-macosx-10.3-i386.egg zope.interface-3.4.1-py2.4-macosx-10.3-i386.egg zope.tal-3.4.1-py2.4.egg zope.tales-3.4.0-py2.4.egg zope.pagetemplate-3.4.0-py2.4.egg The zope.pagetemplate tests pass in this configuration. - C

1 0

release checker bot results.
by Chris McDonough 16 Nov '07

16 Nov '07

Attempting to easy_install all 'zope'-related releases using the script at http://svn.repoze.org/playground/trunk/chris/zopesvnchecker/releasechecker.… , the results were: 122 failures, 67 successes. See http://www.plope.com/static/misc/rcresults-2007-11-14.txt for details. - C

3 5

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

16 Nov '07

Summary of messages to the zope-tests list. Period Thu Nov 15 13:00:00 2007 UTC to Fri Nov 16 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: Thu Nov 15 20:52:52 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008651.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Nov 15 20:54:22 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008652.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Nov 15 20:55:53 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008653.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Nov 15 20:57:23 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008654.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Nov 15 20:58:54 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008655.html

1 0

mapping from collector numbers to launchpad numbers?
by Chris Withers 16 Nov '07

16 Nov '07

Hi All, How do you go about mapping from old collector issue numbers to new launchpad ticket numbers? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

3 3

why external version indexes don't fulfill all use cases for development
by Martijn Faassen 16 Nov '07

16 Nov '07

Hi there, I've been doing some more thinking about external version indexes (like Grok's versions.cfg on a URL, and like KGS) and why they won't solve all our problems. I have a new way to express it, so let me try it out on you all. What KGS solves is that it allows the ongoing development and testing of an integrated Zope 3. That is, there's a Zope 3 'trunk' of versions that keeps being updated as there are bugfix releases. I'm not sure what happens as soon as someone wants to make a new feature release of any package. Presumably they end up in KGS too. After all, we won't have a single Zope 3.4 and then a single Zope 3.5 for which we can create a new KGS. We intend to let packages move at different feature-release speeds, and we can't have a KGS for each package. Another problem KGS can solve is to add some release hygiene to the cheeseshop: do not remove old releases or overwrite them. What KGS doesn't have is history. When I release an application or framework and I used KGS to make sure that all my versions were correct, it will work on the day of release. As soon as enough bugfix (or feature) releases make it to KGS, something will inevitably break. We've seen innocuous changes breaking code a lot of times, so we can't pretend that never happens. It *will* happen. This breaks a fundamental assumption for releases. When I release something, I expect it to work tomorrow, next month, and next year. With code, we know that history, and branches, and so on, are important. We use Subversion. With KGS we only have an ongoing trunk. With Grok, we use an external versions list. We can use this to solve the above problem. We basically take snapshots of what is in KGS. This allows us to maintain some history, though it isn't ideal either, as it's quite a bit of overhead. If I build an application or framework on top of Grok, I will need to maintain yet another external list for the extra packages of this application, fixing those versions. We could probably even use the extends feature of buildout to have this list point at Grok's list so we have to repeat ourselves less should we want to build something on top of *that* application or framework again. So, while annoying, that is somewhat manageable. Now imagine I want to use a completely separate Python library with my Grok application. This python library has dependencies itself again. This means I will need to know about versions of those dependencies as well, and fix them into my application's list. There are some fundamental problems with external lists or indexes: * we need to know about the dependency of dependencies, even if we never use them directly. Information hiding is broken. * a single list will never do it. We intend to have many different applications that may depend on different versions of packages. Grok may need a newer zope.publication than your application does. A Grok extension may need an even newer version than Grok does. We'll be baking endless amounts of lists this way. If this information is inside the packages itself, the history will be automatically maintained with Subversion and existing releases. History therefore works: if I install Grok 0.11, I would get all dependencies of Grok 0.11 automatically without having to worry about external indexes. Information hiding works: if I use foo 1.3 and foo 1.3 knows it needs bar 1.7, it'll simply get that and I don't have to know about it. I don't even need to worry about the *existence* of bar. People have been saying that since Linux distributions use external indexes, we should too, as we are dealing with the same problem as Linux distributions. While the problem is similar, I think the nature of development makes our problems, and therefore our solutions, quite different from the way distributions do it. How are we different? We have many, many different small distributions (package + dependencies) that can be combined. We have such a small distribution for each application. We have such a small distribution for each extension. Not just that. We have such a small distribution for each *release* of an application. We have such a small distribution for each *release* of an extension. I therefore still believe that version dependency information should move out of external indexes and into packages. See also my earlier discussion of these problems and possible solutions: http://faassen.n--tree.net/blog/view/weblog/2007/09/26/0 Regards, Martijn

9 22

at the dawn of the fourth age of Zope
by Martijn Faassen 15 Nov '07

15 Nov '07

Hi there, I just wrote an article about the ages of Zope and the age I think we find ourselves in now on my blog. Enjoy, and I'd be happy to hear comments on it: http://faassen.n--tree.net/blog/view/weblog/2007/11/15/0 Regards, Martijn

1 0

buildout "tests_require" analogue
by Chris McDonough 15 Nov '07

15 Nov '07

Is there an equivalent for "tests_require" in buildout.cfg/ zc.recipe.testrunner? The reason I ask is this... currently the zope.18n distribution has an install_requires that looks something like this: install_requires=[ 'setuptools', 'pytz', 'zope.i18nmessageid', 'zope.component [zcml]', 'zope.configuration', ] That's actually a no-good pack of lies, though. ;-) I'd like to change setup.py to something like this: test_suite = "__main__.alltests", # to support "setup.py test" tests_require=[ 'zope.testing', 'pytz', 'zope.component [zcml]', 'zope.configuration', ], install_requires=[ 'setuptools', 'pytz', 'zope.i18nmessageid', 'zope.component', # *we* do not require zope.configuration at all. Our tests # do (for silly reasons) and the framework which uses our zcml # does. ], But I want buildout tests to continue to work. I suspect the rest of this discussion is going to hurt. ;-) - C

8 12

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

15 Nov '07

Summary of messages to the zope-tests list. Period Wed Nov 14 13:00:00 2007 UTC to Thu Nov 15 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: Wed Nov 14 20:55:01 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008646.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Nov 14 20:56:31 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008647.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Nov 14 20:58:02 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008648.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Nov 14 20:59:34 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008649.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Nov 14 21:01:04 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008650.html

1 0

minimum required for...
by Chris Withers 15 Nov '07

15 Nov '07

Hi All, Kindof related to the packaging discussion... How do I get/install the minimum needed to have: - http/ftp/webdav servers - url publishing - security - component architecture cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0