April 2010 - Zope-Dev

Minutes of this weeks meeting
by Christian Theune 21 Apr '10

21 Apr '10

Hi, here's yesterday's minutes. I've been a bit less adventurous than last week and we're back on a text format. Unfortunately without tool support again, for now. :/ Christian -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development

2 1

zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
by Lennart Regebro 21 Apr '10

21 Apr '10

And here is another interesting experiment: svn+ssh://regebro@svn.zope.org/repos/main/zope.testing/branches/regebro-doctest-patching It replaces the custom doctest.py with monkey-patches. I will report these to the Python bugtracker as well, although I have no hope of getting them into Python 2.7. But that doesn't matter much. :) Benefits: We don't have to maintain a separate doctest.py, and we get the bugfixes from Python. We haven't merged from Python trunk since 2004, and there are LOADS AND LOADS of bugfixes done on the Python doctest which we don't have. There are three bugfixes and two "features" that we have that I now monkey patch in in this branch. Drawbacks: If you import zope.testing.doctest, *all* your doctests will belong to us, so if you have doctests that expect the bugs, your out of luck. :) Also, I do not monkey-patch in the footer parsing support. It's too big, use Manuel instead if you need that. If noone protests, I'll merge this into my "no testrunner branch", make it support Python 3, and then merge that to trunk, maybe sometime next week. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64

9 13

zope.testrunner (Was: Circular dependency hell.)
by Lennart Regebro 21 Apr '10

21 Apr '10

OK, I made a branch of zope.testing that doesn't include the testrunner. That was easy peasy. http://svn.zope.org/zope.testing/branches/regebro-notestrunner/ And I made a zope.testrunner: http://svn.zope.org/zope.testrunner/trunk That was pretty easy too. Except one thing: The shuffle feature shuffles things differently in zope.testrunner compared to in zope.testing.testrunner, which seems to be because it finds the layers in a different order. Anybody using the shuffle feature with seeds in their tests, so we can make sure it still actually works? -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64

4 6

Zope Tests: 10 OK, 4 Failed
by Zope Tests Summarizer 21 Apr '10

21 Apr '10

Summary of messages to the zope-tests list. Period Tue Apr 20 12:00:00 2010 UTC to Wed Apr 21 12:00:00 2010 UTC. There were 14 messages: 6 from Zope Tests, 7 from ccomb at free.fr, 1 from ct at gocept.com. Test failures ------------- Subject: FAILED: Repository policy check found errors in 669 projects From: ct at gocept.com Date: Tue Apr 20 21:14:58 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014041.html Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 32bit From: ccomb at free.fr Date: Tue Apr 20 23:56:07 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014052.html Subject: FAILED : ZTK 1.0dev / Python2.5.2 Linux 32bit From: ccomb at free.fr Date: Tue Apr 20 23:57:33 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014053.html Subject: FAILED : ZTK 1.0dev / Python2.6.4 Linux 32bit From: ccomb at free.fr Date: Tue Apr 20 23:57:38 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014054.html Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Apr 20 21:29:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014042.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Apr 20 21:31:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014043.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Tue Apr 20 21:33:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014044.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Apr 20 21:35:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014045.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Tue Apr 20 21:37:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014046.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Apr 20 21:39:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014047.html Subject: OK : BlueBream template / Python2.4.6 32bit linux From: ccomb at free.fr Date: Tue Apr 20 22:01:21 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014048.html Subject: OK : BlueBream template / Python2.6.4 32bit linux From: ccomb at free.fr Date: Tue Apr 20 22:01:25 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014049.html Subject: OK : BlueBream template / Python2.7b1 32bit linux From: ccomb at free.fr Date: Tue Apr 20 22:01:26 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014050.html Subject: OK : BlueBream template / Python2.5.2 32bit linux From: ccomb at free.fr Date: Tue Apr 20 22:01:27 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014051.html

1 0

"Comply with repository policy" ?
by Hanno Schlichting 21 Apr '10

21 Apr '10

Hi. I've seen lots of checkins recently stating "Comply with repository policy". I haven't seen any announcement of a new official repository policy. Have I missed it? I'd be especially interested who exactly is responsible for changing code so that it complies with the new policy. How much of the initial work is automated and taken care of by some small group of people and what is left to the individual package maintainers? How are packages without maintainers handled? What about trunk vs. old branches? Thanks, Hanno

5 8

Unauthorized handling in Zope2
by Wichert Akkerman 21 Apr '10

21 Apr '10

I can't get an Unauthorized exception view to work with current Zope 2.12 svn. My approach was: - add a dummy PAS challenge plugin which does nothing, effectively delegating everything to my Unauthorized exception view - register a browser view for Unauthorized and return a proper error message there unexpectedly the result is a stock Zope2 site error page. What seems to happen is that everything works correctly, up to this point the zpublisher exception hook in Zope2.App.startup: if issubclass(t, Unauthorized): # Re-raise Unauthorized to make sure it is handled # correctly. We can't do that with all exceptions # because some don't work with the rendered v as # argument. raise t, v, traceback v is the html as generated by my view. Reraising the exception transfers control to the bare except in ZPublisher.Publish.publish_module_standard, which generates the standard site error page and returns that. What is the reason for re-raising Unauthorized there? There is no special processing for it anywhere up in the call stack, so I can see no benefit to it. If I remove that code block so we always return the result of the view everything works as I would expect. Wichert.

2 9

Circular dependency hell.
by Lennart Regebro 21 Apr '10

21 Apr '10

<This is to a large part an angry rant. Sorry for that.> In my effort to port zope.component to Python 3 I constantly encounter one problem that is very hard to solve: Circular dependencies. It's hard to port module A, when running the tests require module B to be ported, and module B depends on module A. Or, as with setuptools, it actually uses itself, so it has to work before you can test if it works. (Sorry, that's just insane). So far the main circularity was that everything depended on zope.testing as a testrunner, zc.buildout for making the development environment, and zope.testing obviously depended on zope.interface etc. I solved that by also adding support for setuptools/distributes testrunner and using that instead. That fixed zope.interface, zope.event and zope.exception. These modules still have buildout configurations if you want them, but you don't need buildout anymore. zope.interface, zope.event and zope.exception can now be developed and tested with only setuptools, you can run the tests with "python setup.py test" both under Python 2 and 3. But then the time came to zope.testing itself. It, rather annoyingly, depends on itself. I did the same there, but almost all tests are even more annoyingly, doctests, and depends on a custom version of doctest included, etc, etc, etc. The result was hours and hours of minor fiddling to find exactly what character in a doctest that made it fail. So I've spent an inordinate amount of time on zope.testing, and I have come to a conclusion about it: == Suggestion 1 == I think we should deprecate zope.testing. Completely. There has been some discussion about deprecating it for something else, but I think we should just deprecate it. Just say "Don't use zope.testing, it's pure evil". We can recommend another testrunner, and it seems nose is winning the wars in the Python world there, but I don't think we necessarily need to do that. Most testrunners will find the tests by themselves, and the tests should be runnable with any testrunner, so which one you use is a minor issue. Instead the big problem with getting rid of zope.testing is that many tests use other specific features like the doctest renormalizers etc. These could possibly be extracted into separate modules so you can use them with other testrunners. But zope.testing is a mess that builds on two other messes, namely unittest (yes, it's a bloody mess, the API makes no sense) and doctest (which is a horror of a mess). unittest and doctest are horrid enough for us to not to make it worse with zope.testing in addition. The path forward there would simply be to stop depending on zope.testing for all ZTK modules. That's probably a bit of work, but I think it's worth it. So, with that in mind I today went on to zc.buildout, trying to port it to Python 3 by ripping out any usage of zope.testing. Also, the standard development mode for zc.buildout is that you run a dev.py script, that uses zc.buildout to build a buildout for zc.buildout. Obviously, this circularity is the same as I encountered in setuptools, and it's evil. But with zc.buildout it's easy to get rid off at least as I could use setuptools testrunner instead. But then I realize the zc.buildout needs zc.recipe.egg. And zc.recipe.egg depends on zc.buildout. Hohum, another circular depedency. == Suggestion 2 == Move the egg recipe into zc.buildout itself, and make zc.recipe.egg a dummy package that just points at zc.buildout.recipe.egg (or whatever we decide to call it). That solves that problem. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64

10 26

Validating invariants with zope.schema.getValidationErrors and zope.schema.Object
by Andrey Popp 20 Apr '10

20 Apr '10

Hello, does anyone know why zope.schema.Object does not check invariants during validation process? If object conforms to schema it implies that object should conform all schema invariants, insn't it? Thanks. -- Andrey Popp phone: +7 911 740 24 91 e-mail: 8mayday(a)gmail.com

2 3

Wanted: representatives from Zope 2, grok, and BlueBream to engineer ZTK 1.0 release
by Christian Theune 20 Apr '10

20 Apr '10

Hi everyone, on the way towards a ZTK 1.0 release we first looked for a single volunteer release manager who would drive the process. As no one stepped up and no (serious) nominations were presented the discussion went back to the drawing board and the plan was changed a bit: we'd like to go with a (small) team of representatives from the large ZTK consumers, namely: Zope 2, grok, and BlueBream. I assume at least someone from every project is listening here, so I suggest the following: * grok and BlueBream: please check within your own sub-communities for someone you'd like to represent you in the draft of what the ZTK 1.0 should look like and who is willing to help with it. * Zope 2: In theory I'd suggest the Zope 2 release manager. In practice I'd like to nominate Hanno because he's been very active with Zope 2 recently and already has done work on the ZTK before. (Hanno: sorry. *duck*) We don't have a complete set of tasks/issues for the release yet, however, here's a few: * Find a definition of 'ZTK release' that fits all consumers * Establish actual task list and work on it * Ensure we have windows binaries We don't have a schedule to follow, but I think we can get started within the next weeks (read that "as soon as we have the staffing issues out of the way"). Cheers, Christian -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development

5 6

zope.i18nmessageid-3.5.1 py2.5 win binary
by Adam Groszer 20 Apr '10

20 Apr '10

Hello, Someone please make a release of the above. -- Best regards, Adam

2 1