October 2009 - Zope-Dev

Zope 2 WebDAV and acquisition
by Martin Aspeli 09 Oct '09

09 Oct '09

Hi, In my travails through the ZPublisher and WebDAV, I've come up with another fun thing. As far as I can tell, traversal via acquisition doesn't make any sense for a WebDAV request. If I have /foo and /bar, but not /bar/foo, then traversal to /bar/foo over WebDAV should not acquire /foo and wrap it in /bar. One reason for this (apart from being utterly confusing) is that it breaks PUT requests to a NullResource: If I try to PUT to /bar/foo it should create a new object there, not overwrite /foo. There is actually some convoluted support for detecting this in ZPublisher.BaseRequest: # Note - no_acquire_flag is necessary to support # things like DAV. We have to make sure # that the target object is not acquired # if the request_method is other than GET # or POST. Otherwise, you could never use # PUT to add a new object named 'test' if # an object 'test' existed above it in the # heirarchy -- you'd always get the # existing object :( if (no_acquire_flag and hasattr(parents[1], 'aq_base') and not hasattr(parents[1],'__bobo_traverse__')): if not (hasattr(parents[1].aq_base, entry_name) or parents[1].aq_base.has_key(entry_name)): raise AttributeError, entry_name This doesn't really work, though. The object is acquired, and then all it does is to check that the PUT() method object is a true attribute of the acquired object. But even then, raising AttributeError is wrong. What should happen, I think, is that in DefaultPublishTraverse.publishTraverse() we should *not* attempt to acquire for webdav requests. Instead, we should try direct attribute access and then __getitem__() access (which is the next thing it tries after getattr() acquisition). This would then allow the folder to return a NullResource (as OFS.ObjectManager does, for example). Any objections? It's a relatively simple condition in DfaultPublishTraverse.publishTraverse(). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

3 8

Re: [Zope-dev] SVN: zc.buildout/trunk/src/zc/buildout/buildout.py comparing requirement locations instead of requirement objects
by Martijn Faassen 08 Oct '09

08 Oct '09

Tarek Ziade wrote: > Log message for revision 104933: > comparing requirement locations instead of requirement objects Did I miss the CHANGES.txt update? Regards, Martijn

1 0

allow-picked-versions=false in ztk.cfg?
by Martijn Faassen 08 Oct '09

08 Oct '09

Hi there, To quote Thomas Lotze in another discussion: > [ztk.cfg] contains a line > allow-picked-versions = false > which makes buildout complain if it ends up using a package whose > version it had to pick from the index, so you're required to specify a > version for every package used by any part of the buildout. This line > is a piece of policy that I'd like to see gone from ztk.cfg as well; > if someone wants the behaviour, they can specify it in their > buildout.cfg. I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it. The question though is why this is in there in the first place. Presumably it is to ensure that the *ZTK* locks down all versions. I think we can reasonably ensure this by moving the 'allow-picked-versions' to the ZTK's "buildout.cfg" instead, right? Regards, Martijn

6 12

Zope Tests: 8 OK
by Zope Tests Summarizer 08 Oct '09

08 Oct '09

Summary of messages to the zope-tests list. Period Wed Oct 7 12:00:00 2009 UTC to Thu Oct 8 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 Oct 7 20:48:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012728.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Oct 7 20:50:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012729.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Wed Oct 7 20:52:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012730.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Wed Oct 7 20:54:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012731.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Wed Oct 7 20:56:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012732.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Oct 7 20:58:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012733.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Wed Oct 7 21:00:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012734.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Oct 7 21:02:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012735.html

1 0

Removing zope.testrecorder from the ZTK
by Thomas Lotze 08 Oct '09

08 Oct '09

I just noticed that zope.testrecorder, which is listed in ztk.cfg as an included package, imports from Globals, OFS, AccessControl and Products.PageTemplates. This looks to me as if zope.testrecorder shouldn't actually be part of the ZTK. It's also not used by any package mentioned in ztk.cfg. -- Thomas

6 6

Updating the ZTK KGS
by Thomas Lotze 07 Oct '09

07 Oct '09

Having worked on and released new versions of a few ZTK packages recently, I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as there doesn't seem to be an agreed process about this and in an attempt not to step on anyone's toes, I'd like to ask first whether it is OK for any developer to modify the versions listed in ztk.cfg (provided that all relevant tests are passing, of course). I'd currently like to update the following packages: zope.app.apidoc = 3.6.7 zope.app.publication = 3.9.0 zope.error = 3.7.0 zope.location = 3.7.0 zope.site = 3.7.0 zope.traversing = 3.8.0 -- Thomas

4 8

zope.filerepresentation release
by Martin Aspeli 07 Oct '09

07 Oct '09

Hi, Following an earlier discussion on this list, I've made changes to zope.filerepresentation to incorporate two new interfaces, IRawReadFile and IRawWriteFile. These allow file representation adapters which behave like Python standard library 'file' objects. This in turn allows implementation of efficient reading/writing or large files (without loading everything into memory), ZServer streaming support, and the use of file representation adapters in contexts that expect a standard file. The changes are 100% backwards compatible: they merely add two interfaces. I'd very much like a release of this. :) Would anyone mind making a 3.5.1 release, or else give me PyPI rights so that I can do it myself. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

4 5

Grok 1.0 released!
by Martijn Faassen 07 Oct '09

07 Oct '09

Hey, Yay! Zope's caveman spin-off, Grok, finally got its 1.0 release today! http://grok.zope.org Thanks should also go to all Zope hackers for helping to provide the foundation for Grok! Regards, Martijn

1 0

Zope Tests: 8 OK
by Zope Tests Summarizer 07 Oct '09

07 Oct '09

Summary of messages to the zope-tests list. Period Tue Oct 6 12:00:00 2009 UTC to Wed Oct 7 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 Oct 6 20:44:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012720.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Oct 6 20:46:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012721.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Tue Oct 6 20:48:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012722.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Tue Oct 6 20:50:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012723.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Tue Oct 6 20:52:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012724.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Tue Oct 6 20:54:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012725.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Tue Oct 6 20:56:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012726.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Tue Oct 6 20:58:58 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012727.html

1 0

Subversion externals versus mirroring
by Christian Theune 06 Oct '09

06 Oct '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, a long-standing issue with our mirror of svn.zope.org are the absolute URLs of externals: they require the repository to be available on a given URL. I propose to use relative URLs for externals. I guess a complete update isn't necessary, but I'd like to improve the situation and start using them from now on. Maybe we should also put a commit hook in place as a safety belt? However, this requires Subversion 1.5 which we are using on the server already, but I don't know whether we assume clients are 1.5 or higher. As a side effect this will also make svn/svn+ssh work in a nicer way (IMHO) as the externals will follow the protocol of what you used for checkout. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqnoB8ACgkQdUt9X/gknwI9lgCcDjO320EGllkcaJT8rA7aR+pa rVIAn2Qh5D7sIGMmNPSyClx72PHBhL80 =5696 -----END PGP SIGNATURE-----

18 31