August 2009 - Zope-Dev

Re: [Zope-dev] SVN: Sandbox/nadako/zope.app.publisher/ Clean up dependencies.
by Tres Seaver 27 Aug '09

27 Aug '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Richter wrote: > On Thursday 27 August 2009, Tres Seaver wrote: >> Stephan Richter wrote: >>> On Thursday 27 August 2009, Dan Korostelev wrote: >>>> extras_require={ >>>> 'test': ['zope.testing', >>>> 'zope.app.testing', >>>> 'zope.app.securitypolicy', >>>> 'zope.app.zcmlfiles', >>>> + 'zope.container>=3.8.3', >>>> 'zope.site'], >>> You can not require a minor version in setup.py. >> Huh? setuptools doesn't care about how many dots are in the dependency. > > This is not a technical but a process requirement that we discussed on the > mailing list and was captured in the steering committee decision list. OK: "can not" signalled something different to me. It happens that the particular case here requires bending that rule, I think (3.8.2 just won't work with the package). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKluMA+gerLs4ltQ4RAkKxAJ40c6cXv4RYvr/JEGU2rpNscMR0PQCgn3SA ZnzGase5cDZ73z+4qOZ3X1Y= =trbt -----END PGP SIGNATURE-----

1 0

List of packages in ZTK
by Christian Theune 27 Aug '09

27 Aug '09

Hi, I took the Zope 3.4 KGS, removed the obvious packages that do not belong to the ZTK out of the list and created a home for the master list that defines which packages belong to the ZTK. It's in the Zope toolkit documentation: http://docs.zope.org/zopetoolkit/about/packages.html So, if you see that a package is missing or is classified in the wrong way, then please speak up. 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 7 · fax +49 345 1229889 1 Zope and Plone consulting and development

9 25

Zope Tests: 8 OK
by Zope Tests Summarizer 27 Aug '09

27 Aug '09

Summary of messages to the zope-tests list. Period Wed Aug 26 12:00:00 2009 UTC to Thu Aug 27 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Aug 26 20:43:51 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012392.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Aug 26 20:45:51 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012393.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Wed Aug 26 20:47:51 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012394.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 26 20:49:51 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012395.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Wed Aug 26 20:51:52 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012396.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 26 20:53:52 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012397.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 26 20:55:52 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012398.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 26 20:57:52 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012399.html

1 0

zope.sendmail and testing
by Jan-Wijbrand Kolman 26 Aug '09

26 Aug '09

Hello, We're using zope.sendmail to send mail from our applications. These applications are built on top of a more generic application library. It is this application library that depends on zope.sendmail. This application library listens for certain events and then can decide to send out an email. Obviously, when running the tests for the concrete application no mail is allowed to be actually sent. Zope.sendmail explains in its README.txt that the developer using zope.sendmail should himself take care of not sending emails (by setting up a test layer for example, that would register a no-op IMailDelivery utility). I had hoped that somehow zope.sendmail would automagically "detect" it is used during test runs and then would not send out any mails. I dug around in zope.testing and found the cleanup module that seems to provide (if I understand correctly) a global registry of things to cleanup after tests. I wonder if this could be extended to also be able to register routines for globally setting up stuff - in this case it could stub the mail delivery so that never ever any mail is actually send out when running tests. Questions: 1) how do others make sure that applications that directly or indirectly trigger sending mails do not actually send during testing? 2) am I on the right track thinking a "set up" equivalent of zope.testing.cleanup could be useful for these cases? kind regards, jw -- Jan-Wijbrand Kolman

4 6

Zope Tests: 8 OK
by Zope Tests Summarizer 26 Aug '09

26 Aug '09

Summary of messages to the zope-tests list. Period Tue Aug 25 12:00:00 2009 UTC to Wed Aug 26 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Aug 25 20:43:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012384.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Aug 25 20:45:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012385.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Tue Aug 25 20:47:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012386.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Tue Aug 25 20:49:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012387.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Tue Aug 25 20:51:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012388.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Tue Aug 25 20:53:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012389.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Tue Aug 25 20:55:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012390.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Tue Aug 25 20:57:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012391.html

1 0

zope.app.publisher refactoring status
by Dan Korostelev 25 Aug '09

25 Aug '09

Hi people. As you might notice, I was refactoring zope.app.publisher in my sandbox. The work is mostly done now, apart from couple of things still in question. Four new packages have been introduced: * zope.browsermenu - browser menu system, without any changes. :-) * zope.browserpage - browser:page directive and friends. the directives was changed to support menu item registration only when zope.browsermenu is available, simply ignoring (and raising a warning) the "menu" argument otherwise. * zope.browserresource - resource system and browser:resource directive and friends. file-based resources now supports pluggable resource class lookup based on file extension (implementation based on this patch - https://bugs.launchpad.net/zope3/+bug/98459) this allows to separate pagetemplate resources into another package as well as support registering specific resource factories for some extensions (.zrt for example). * zope.ptresource - the page template resource that was moved into a separate package to make zope.browserresource independent from zope.pagetemplate. it's now a plugin for zope.browserresource - a custom resource factory, registered for "pt", "zpt" and "html" extensions. The ModifiableBrowserLanguages adapter was moved into zope.publisher.browser, as well as some ZCML security declarations defined for zope.publisher's classes. Things left in zope.app.publisher are still to be discussed. First, the "Browser Skins" vocabulary - a vocabulary of IBrowserSkinType utilities. It could be moved to zope.publisher, but it introduces dependency on zope.componentvocabulary, which is not needed for zope.publisher currently. So there's three options to choose from: a) Move it to zope.publisher, introducing a dependency on zope.componentvocabulary for it. b) Move it to zope.publisher, rewriting the vocabulary to use zope.schema's SimpleVocabulary and not introducing dependency on zope.componentvocabulary. c) Leave it there as is. I think, that it's a nice option, since "Browser Skins" vocabulary doesn't seem to be used anywhere by other zope packages and can be easily recreated if someone will need it. Second, the "browser:defaultView" and "browser:defaultSkin" directives. The functionality of default views and default skins is currently contained in zope.publisher, and these directives only provide a way to configure default view/skin via ZCML. I think that these directives should be moved to zope.publisher as well, since it seems the right place for them and the move won't introduce extra dependencies for zope.publisher. Third, the "xmlrpc:view" directive and the XML-RPC method publisher. It's a nice thing, but people doesn't seem to be interested very much in XML-RPC these days. Also, it seems that zope.publisher will be refactored soon, so the future of xmlrpc modules is not clear. I see two options for this thing: a) Extract it into the new, "zope.xmlrpc" module. b) Leave it there as is. If noone demonstrates interest in discussing the xmlrpc, I'll probably choose option b :-) The code is available in svn://svn.zope.org/repos/main/Sandbox/nadako/zope.app.publisher/. It will also check out newly created packages via svn:externals, so all you need for testing is simply checkout zope.app.publisher from my sandbox. -- WBR, Dan Korostelev

2 2

Re: [Zope-dev] IRC discussion about testing
by Jim Fulton 25 Aug '09

25 Aug '09

2009/8/3 Fabio Tranchitella <fabio(a)tranchitella.it>: > Hi, Hi, I've added zope-dev. I hope you don't mind. > > * 2009-08-03 08:59, Christian Theune wrote: >> Cool! Thanks for helping out! I should be online most of the time and >> I'd be happy to answer questions. > > Tonight I spent some time working on this, and I wrote a mock-up of my idea > for testing the KGS. I did not want to change anything in compattest, so I > created a new recipe called z3c.recipe.kgs. Later on we can merge things > back into compattest. > > You can get the recipe from here: > > svn://svn.zope.org/repos/main/z3c.recipe.kgs/trunk > > There are no tests nor documentation, because it is a mock-up and I did not > want to spend time on writing documentation for something that maybe is not > exactly what we need. > > Let's say that you are working on transaction and you want to test your > changes against the KGS, you can simply add the following snippet to your > buildout.cfg: > > [test-kgs] > recipe = z3c.recipe.kgs > kgs = http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packa… > > You can now run buildout, and you will get ./bin/test-kgs-<package> for > each package in the KGS, as well as ./bin/test-kgs to run all the tests in > all the packages in isolated environments. > > The KGS is rather big right now, so I suggest to try it with a subset of > the packages using something like: > > [test-kgs] > recipe = z3c.recipe.kgs > kgs = http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packa… > packages = zope.component > zope.interface > zope.event > zope.configuration > > Now.. this simple recipe allows us to test a local change in a package we > are developing on running the tests of all the packages that are part of a > KGS. In fact, it reuses the KGS as defined in zope.release, without > reinventing the wheel, and it is quite generic. > > Ideas? Comments? Is this the right direction? I think this is the right direction. :) A number of comments below: - I just tried this out. Unfortunately, I'm getting lots of test failures using Python 2.5. That's not the recipe's fault. :) - A bigger problem is that the runner of all tests eventually dies with too many open files on Mac OS X. Here's the last part of the output: ... Running test-kgs-zope.app.intid Running test-kgs-zope.app.keyreference Running test-kgs-zope.app.layers Running test-kgs-zope.app.locales 1Running test-kgs-zope.app.localpermission Running test-kgs-zope.app.locking Traceback (most recent call last): File "bin/test-kgs", line 259, in <module> File "/private/tmp/kgs/zc.recipe.kgs/src/z3c/recipe/kgs/runner.py", line 86, in main File "/private/tmp/kgs/zc.recipe.kgs/src/z3c/recipe/kgs/runner.py", line 33, in start File "/usr/local/python/2.5.1/lib/python2.5/subprocess.py", line 593, in __init__ File "/usr/local/python/2.5.1/lib/python2.5/subprocess.py", line 1002, in _execute_child OSError: [Errno 24] Too many open files - The packages from zope.release don't build for me on Windows because of a dependency on M2Crypto from keas.kmi. Not a big deal at this point, since ultimately, we want to use a smaller set. - The versions specified in the controlled-packages.cfg don't seem to be honored except for the package being tested. For example, ZODB3-3.9.0b2 is used for test-kgs-ZODB3, but 3.9.0b5 is used for everything else. Fortunately, it appears I can work around this using a buildout versions section. Thanks! Jim -- Jim Fulton

4 11

ZTK and Python 2.6, zope.app.zcmlfiles and zope.app.security globalmodules.zcml
by Jim Fulton 25 Aug '09

25 Aug '09

I'm trying to get the ZTK KGS tests working with Python 2.6. The tests generate lots of deprecation warnings in part because lots of packages use zope.app.zcmlfiles and zope.app.zcmlfiles includes globalmodules.zcml in zope.app.security and globalmodules.zcml causes lots of standard modules to get imported, including mhlib, which is deprecated in Python 2.6. Whew. :) I know we want to stop using zope.app.zcmlfiles. This make take a while. Too big a job for right now. We should stop using globalmodules.zcml. It's too expensive, too scary, and causing this deprecation warning. If I just delete it's contents, no ztk tests break. :/ I see 3 options, from lowest to highest (but maybe still low) risk: A. Suck it up and live with the deprecation warnings until we get rid of zope.app.zcmlfiles B. Remove the security declaration for mhlib from globalmodules.zcml. Is anyone actually building web applications that publish MH mail folders? C. Stop including globalmodules.zcml from zope.app.zcmlfiles Opinions? FWIW, I vote for B. Jim -- Jim Fulton

3 3

Move implementation of getParent to zope.location?
by Thomas Lotze 25 Aug '09

25 Aug '09

There are two functions in zope.traversing.api, getParent and getParents, that are rather closely related. The former is implemented right in that module while the latter adapts its argument to zope.location.interfaces.ILocationInfo and calls getParents() on that. Why is getParent not a part of ILocationInfo? If there's no good reason, I'd propose adding getParent() to the interface and changing the getParent function in zope.traversing to work similarly to getParents, i.e. call a method on an ILocationInfo adapter. -- Thomas

3 4

Re: [Zope-dev] [Checkins] SVN: zope.publisher/trunk/ Moved dependency on zope.testing from install_requires to tests_require.
by Fabio Tranchitella 25 Aug '09

25 Aug '09

Hello, * 2009-08-08 16:20, Hanno Schlichting wrote: > On Sat, Aug 8, 2009 at 2:33 PM, Fabio Tranchitella<kobold(a)kobold.it> wrote: > > Log message for revision 102578: > > Moved dependency on zope.testing from install_requires to tests_require. > > I thought we were not using tests_require yet, as it doesn't work with > zope.testing / buildout properly. Instead we use extra requires named > test for this purpose. In zope.component we use tests_require, in the very same way, for example. Shall I remove it there, too? Is there a policy/document which explains how we use extras and tests_require? > I'm a bit hesitant to introduce a test extra if it is just for > zope.testing, though. The complication introduced by the extra doesn't > seem to outweigh the advantage of loosing that one package to me. To me it looks weird: tests_extra is there for this specific reason. Why shouldn't we use it? Thanks. Fabio

3 5