Re: [Zope-dev] Zope 2.12.0 released
Hi, I have tried to install it on an windows: the egg for python 2.4 works, but the one for 2.6 fails with the following error: Installed d:\pythonfarms\python262\lib\site-packages\zope2-2.12.0-py2.6-win32.egg Processing dependencies for Zope2==2.12.0 Searching for zope.container Reading http://pypi.python.org/simple/zope.container/ Best match: zope.container 3.9.0 Downloading http://pypi.python.org/packages/source/z/zope.container/zope.container-3.9.0.tar.gz#md5= 8a993c12fdbd017a408af62fb75cae39 Processing zope.container-3.9.0.tar.gz Running zope.container-3.9.0\setup.py -q bdist_egg --dist-dir c:\docume~1\admini~1\locals~1\temp\eas y_install-lobg1o\zope.container-3.9.0\egg-dist-tmp-a2hqwi error: Setup script exited with error: Unable to find vcvarsall.bat Thank you very much, Dragos On Thu, Oct 1, 2009 at 6:38 PM, Hanno Schlichting ha...@hannosch.eu wrote: On Thu, Oct 1, 2009 at 6:09 PM, Chris Withers ch...@simplistix.co.uk wrote: Hanno Schlichting wrote: Yeah! I added the Windows binary eggs for Python 2.4 to 2.6 to PyPi. Someone still needs to do this for: http://pypi.python.org/pypi/ExtensionClass/2.11.3 I would, but I don't have the right PyPI access... Thanks. I added the missing binary eggs for the 2.11.2 and 2.11.3 releases. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) -- Dragos Chirila objectval...@gmail.com (+4) 0722 395375 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 released
Dragos Chirila wrote: Hi, I have tried to install it on an windows: the egg for python 2.4 works, but the one for 2.6 fails with the following error: This is because there was no 2.6 binary egg. I've just rolled one and uploaded it. Can you try again and let me know how you go? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.filerepresentation release
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 released
Am 05.10.09 11:49, schrieb Chris Withers: Dragos Chirila wrote: Hi, I have tried to install it on an windows: the egg for python 2.4 works, but the one for 2.6 fails with the following error: This is because there was no 2.6 binary egg. I've just rolled one and uploaded it. Can you try again and let me know how you go? Any suggestion how we can better check the availablity of all related eggs? I have some code for building the KGS on download.zope.org for a given release tag. We might extend the code for checking the availablity of the windows eggs for the supported Python versions...any taker? Andreas attachment: lists.vcf___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 released
Hi Chris, The installation worked smoothly. Still, I had to modify something in the site-packages\zope\interface\common\interfaces.py file : try: classImplements(OverflowWarning, IOverflowWarning) except NameError: pass # OverflowWarning was removed in Python 2.5 Otherwise, Zope wont start because of a Python error: NameError: name 'OverflowWarning' is not defined Thank you very much, Dragos On Mon, Oct 5, 2009 at 11:49 AM, Chris Withers ch...@simplistix.co.uk wrote: Dragos Chirila wrote: Hi, I have tried to install it on an windows: the egg for python 2.4 works, but the one for 2.6 fails with the following error: This is because there was no 2.6 binary egg. I've just rolled one and uploaded it. Can you try again and let me know how you go? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- Dragos Chirila objectval...@gmail.com (+4) 0722 395375 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 released
Dragos Chirila wrote: Hi Chris, The installation worked smoothly. Still, I had to modify something in the site-packages\zope\interface\common\interfaces.py file : try: classImplements(OverflowWarning, IOverflowWarning) except NameError: pass # OverflowWarning was removed in Python 2.5 Otherwise, Zope wont start because of a Python error: NameError: name 'OverflowWarning' is not defined This doesn't seem right. I'm running Zope 2.12 on Windows and haven't had to modify anything. How did you try and install Zope? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 released
I took the steps: - installed Python 2.6.2 - downloaded Zope2-2.12.0-py2.6-win32.egg - ..\Scripts\easy_install.exe Zope2-2.12.0-py2.6-win32.egg - create a zope instance with ..\Scripts\mkzopeinstance.exe Is this the correct way, right? On Mon, Oct 5, 2009 at 12:35 PM, Chris Withers ch...@simplistix.co.uk wrote: Dragos Chirila wrote: Hi Chris, The installation worked smoothly. Still, I had to modify something in the site-packages\zope\interface\common\interfaces.py file : try: classImplements(OverflowWarning, IOverflowWarning) except NameError: pass # OverflowWarning was removed in Python 2.5 Otherwise, Zope wont start because of a Python error: NameError: name 'OverflowWarning' is not defined This doesn't seem right. I'm running Zope 2.12 on Windows and haven't had to modify anything. How did you try and install Zope? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) -- Dragos Chirila objectval...@gmail.com (+4) 0722 395375 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 released
Dragos Chirila wrote: I took the steps: - installed Python 2.6.2 - downloaded Zope2-2.12.0-py2.6-win32.egg - ..\Scripts\easy_install.exe Zope2-2.12.0-py2.6-win32.egg - create a zope instance with ..\Scripts\mkzopeinstance.exe Try the virtualenv option here: http://docs.zope.org/zope2/releases/2.12/INSTALL.html#installing-zope-using-easy-install It sounds like you have old cruft in your site-packages which is tripping Zope up... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation release
Hi. On Mon, Oct 5, 2009 at 12:13 PM, Martin Aspeli optilude+li...@gmail.com wrote: 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. I gave you owner rights for this package. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation release
Hello, * 2009-10-05 12:15, Martin Aspeli wrote: Would anyone mind making a 3.5.1 release, or else give me PyPI rights so that I can do it myself. Shouldn't this be 3.6.0? Best regards, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation release
Fabio Tranchitella wrote: Hello, * 2009-10-05 12:15, Martin Aspeli wrote: Would anyone mind making a 3.5.1 release, or else give me PyPI rights so that I can do it myself. Shouldn't this be 3.6.0? I don't care one way or the other. 3.6.0 is fine by me. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation release
On Mon, Oct 5, 2009 at 1:18 PM, Martin Aspeli optilude+li...@gmail.com wrote: Fabio Tranchitella wrote: * 2009-10-05 12:15, Martin Aspeli wrote: Would anyone mind making a 3.5.1 release, or else give me PyPI rights so that I can do it myself. Shouldn't this be 3.6.0? I don't care one way or the other. 3.6.0 is fine by me. 3.6.0 sounds better. It's a new feature and not a bugfix. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Sun Oct 4 12:00:00 2009 UTC to Mon Oct 5 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: Sun Oct 4 20:50:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012704.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun Oct 4 20:52:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012705.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Sun Oct 4 20:54:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012706.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Sun Oct 4 20:56:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012707.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Sun Oct 4 20:58:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012708.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Sun Oct 4 21:00:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012709.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Sun Oct 4 21:02:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012710.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Sun Oct 4 21:04:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012711.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Updating the ZTK KGS
Thomas Lotze wrote: 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 Thanks for bringing this up. There's indeed currently no agreed-upon process. Jim a while ago was proposing a rather heavy staging process where the trunk can only be changed if a staged branch passed all tests on all platforms (and Python versions) as run by a buildbot. We don't have the infrastructure for this yet and Christian Theune and I were wondering whether this is needed. An alternative process would be to only *release* the ZTK after the compat tests run on all platforms as shown by the buildbot. We do have infrastructure for that. So I'd propose the following development process: * developers can change the version numbers in the ZTK * if the compattests all run, they can check in And then for releases: * we determine we want to make a release of the ZTK * if the buildbot reports it all works on all platforms * we verify there have been no further modifications since then * we can release * what does a release look like exactly? We should at least have a documentation release sitting somewhere on docs.zope.org, with the release number in the URL. The 'current' URL should also point to this documentation. Along with this we should also publish the lists of versions for reuse. How? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 released
Chris, You were right; I tried on a fresh Python 2.6.3 installation and it worked - Zope instance started without errors. Dragos On Mon, Oct 5, 2009 at 12:43 PM, Chris Withers ch...@simplistix.co.uk wrote: Dragos Chirila wrote: I took the steps: - installed Python 2.6.2 - downloaded Zope2-2.12.0-py2.6-win32.egg - ..\Scripts\easy_install.exe Zope2-2.12.0-py2.6-win32.egg - create a zope instance with ..\Scripts\mkzopeinstance.exe Try the virtualenv option here: http://docs.zope.org/zope2/releases/2.12/INSTALL.html#installing-zope-using-easy-install It sounds like you have old cruft in your site-packages which is tripping Zope up... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- Dragos Chirila objectval...@gmail.com (+4) 0722 395375 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Updating the ZTK KGS
Martijn Faassen wrote: So I'd propose the following development process: * developers can change the version numbers in the ZTK * if the compattests all run, they can check in I'll go ahead and update the KGS with my proposed new versions then; if someone experiences a problem with this, feel free to flame me ;o) * what does a release look like exactly? We should at least have a documentation release sitting somewhere on docs.zope.org, with the release number in the URL. The 'current' URL should also point to this documentation. Along with this we should also publish the lists of versions for reuse. How? I see two options: - make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a versioned URL - release a ztk egg that depends on the exactly versioned packages The latter is probably the more reusable. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Updating the ZTK KGS
On Mon, Oct 5, 2009 at 4:44 PM, Thomas Lotze t...@gocept.com wrote: I see two options: - make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a versioned URL - release a ztk egg that depends on the exactly versioned packages The latter is probably the more reusable. I'd suggest to follow the Zope2 approach and provide both an index and a versions.cfg at a permanent place. The result looks like this: http://download.zope.org/Zope2/index/2.12.0/ You can use this with both easy_install and buildout easily. Andreas wrote a very simple script that is able to produce such a minimal listing. I don't see how a ZTK meta-egg would be of any value. Given that the number of packages included in the ZTK will change quite a bit over time, it doesn't make sense to depend on a ZTK egg for a package, as it doesn't provide any real stable contract. An egg with hard coded exact version numbers is pretty painful as well, as you cannot override those requirements to go for selected newer versions of any packages pinned in such a way. Opting for a newer zope.testing release for example is quite a common requirement. I don't think it makes sense for anyone to install the entire ZTK. Projects being built on top of the ZTK are most often only interested in a part of the ZTK and will depend on such packages explicitly. What is valuable for those, is the stability contract between various versions of packages in the ZTK. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2 WebDAV and acquisition
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
Martin Aspeli wrote: Martin Aspeli wrote: Martin Aspeli wrote: 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(). Actually, I found some code that may be trying to address this (although I think it's probably likely that not attempting to acquire in the first place is better). Basically, it allows acquisition during traversal, but when you get to the end of the path, it does this: if (no_acquire_flag and hasattr(object, 'aq_base') and not hasattr(object,'__bobo_traverse__')): if object.aq_parent is not object.aq_inner.aq_parent: from webdav.NullResource import NullResource object = NullResource(parents[-2], object.getId(), self).__of__(parents[-2]) This would fix the problem, except in my case, the traversed-to object (/foo in the example above) happens to have a __bobo_traverse__(), as do all CMF types, so the third caluse of the first if statement is false. I can't see the logic here, though: why would it matter if the acquired object happens to have a __bobo_traverse__? Removing that condition fixes it for me. This would be an even simpler bug fix (though I still find it fishy that you can acquire folders through WebDAV). Can anyone explain why that condition is there? Otherwise, I'll rip it out. ;-) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book Martin Aspeli wrote: 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
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
(updating myself much much later) Chris Withers wrote: yuppie wrote: You ripped my sentence out of context. We were talking about Zope 2.12. And Zope 2.12 currently doesn't use buildout for setting up instances. Sure it does. I've published the recipe. There's no more needed than that... Your recipe is not published as part of Zope 2.12. I'm not sure it needs to... It will be once Jens cranks the handle: http://svn.zope.org/Zope/branches/2.12/doc/INSTALL.rst?rev=104817view=auto And it doesn't work on Windows. Have you tried it? ...if you had, you would have noticed that the Win32 service stuff as broken, even without using buildout. I've now fixed that, and I'm happy to report that the buildout-based instances work just fine on Windows, and buildout instance or not, you no longer need that silly zopeservice.py file in your instance. So, no excuse for needing mkzopeinstance and its ilk anymore ;-) Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
Martin Aspeli wrote: Can anyone explain why that condition is there? Otherwise, I'll rip it out. ;-) As I recall, this code is convoluted because it's hard to tell whether an HTTP request is a WebDAV request. If there is now a way to clearly distinguish WebDAV requests, then I imagine this code can be greatly simplified. This code had to deal with Windows 95 and such. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
Shane Hathaway shane at hathawaymix.org writes:
Martin Aspeli wrote:
Can anyone explain why that condition is there? Otherwise, I'll rip it
out.
As I recall, this code is convoluted because it's hard to tell whether
an HTTP request is a WebDAV request. If there is now a way to clearly
distinguish WebDAV requests, then I imagine this code can be greatly
simplified. This code had to deal with Windows 95 and such.
Well, at the very least, you can use the check that says:
if request.maybe_webdav_client and \
request['HTTP_REQUEST_METHOD'] not in ('GET', 'POST'):
This wouldn't solve the problem for WebDAV GET or POST requests, but that's
actually fine. The problem seen here mainly pertain to PUT and PROPFIND
requests.
This would meant that there's a chance people could get a weird acquisition
chain on a GET request that then wouldn't resolve properly (giving a 404) on a
subsequent PROPFIND or PUT, but this is very unlikely to happen in practice
unless someone (a) overrode listDAVObjects() to return acquired objects or (b)
manually entered a WebDAV URL that resulted in acquisition, and which was only
used for a GET.
Compared to the situation right now where PUT is broken for any file that has
the same name as an object higher up in the acquisition chain, not supporting
these arguably-invalid edge cases seems a lot better. :)
Martin
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
