[Zope-dev] Changelog formatting [was: SVN: cmf.pt/trunk/ Preparing release.]
Malthe Borch wrote: Log message for revision 94141: Preparing release. Changed: U cmf.pt/trunk/CHANGES.txt U cmf.pt/trunk/setup.py -=- Modified: cmf.pt/trunk/CHANGES.txt === --- cmf.pt/trunk/CHANGES.txt 2008-12-17 11:44:23 UTC (rev 94140) +++ cmf.pt/trunk/CHANGES.txt 2008-12-17 12:52:37 UTC (rev 94141) @@ -1,7 +1,7 @@ Changelog = -In next release +cmf.pt 0.2 (released 12/17/2008) I've noticed you're using the U.S. date format here which we discourage due to its ambiguity (in this case it happens not to be ambiguous, but that's just coincidence). The preferred format is the ISO 8601 dash notation (-MM-DD). This and other things, such as the proper formatting of changelogs, are documented in a guide called Maintaining Software in the Zope Software Repository [1] of which Releasing Software [2] is a chapter. I admit they're not in the most public place, I'm just the guy who wrote them (by codifying best practices). Anybody who'd like to put them somewhere more visible is most welcome to (e.g. the Grok folks have put the Releasing Software document on their website [3]). Happy holidays everyone, Philipp [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt [2] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt [3] http://grok.zope.org/documentation/how-to/releasing-software ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.sendmail/trunk/ Copied over the UtilityTerm and UtilityVocabulary implementation from zope.app.component to avoid a dependency.
Hanno Schlichting wrote: Benji York wrote: On Fri, Nov 14, 2008 at 7:23 PM, Hanno Schlichting [EMAIL PROTECTED] wrote: Log message for revision 92953: Copied over the UtilityTerm and UtilityVocabulary implementation from zope.app.component to avoid a dependency. Instead of duplicating the code there should be a zope.utilityvocabulary package that both zope.sendmail and zope.app.component can use. I agree in principal. In this case the code is extremely tiny, though. I'm not sure if packages which consist of only two simple classes are really that much of a good idea. There is an overhead in tracking dependencies and maintaining packages in itself. When the benefit of being able to reuse the same code outweighs this overhead is not clear to me. If it's tiny, then the overhead is there only once, when the package is created and released, right? After than you can just leave it alone and never ever have to think about it again. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 features
Jens Vagelpohl wrote: On Nov 4, 2008, at 13:59 , Hanno Schlichting wrote: If I'm not mistaken there was something about every release being supported two years after its initial release in those discussions. But time went on, we haven't sticked to a time-based release schedule and those policies haven't been written down or been followed. 2 years sounds fine to me. By that reasoning, we can stop supporting 2.8 (2.8.0 was released June 11, 2005) and 2.9 (2.9.0 was released January 9, 2006). However, if we were strict it would also mean EOL for 2.10 (2.10.0 was released October 4, 2006). But we can be lenient... +1 to retiring 2.8, 2.9. Of course, if people still want to maintain it, they should be welcome to. I just don't think we should have to merge bugfixes to those branches anymore. Maintaining 2.10, 2.11, trunk seems perfectly acceptable and it's plenty to deal with. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.relationship 1.0.2 typo bug
Rudá Porto Filgueiras wrote: I found a typo bug in zc.relationship 1.0.2 (pypi and svn tag 1.02). It's fixed in trunk but not backported and plone.app.relations-1.0b2 unittest found this bug. Thanks for the bug report and the patch. Could you please report it at https://bugs.launchpad.net/zope3? Thank you! ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.container won't compile
Andreas Jung wrote: On 19.10.2008 14:14 Uhr, Andreas Jung wrote: On 19.10.2008 14:04 Uhr, Roger Ineichen wrote: Hi Andreas Betreff: [Zope-dev] zope.app.container won't compile A buildout fails reproducable both on Mac and Linux...how is the guilty? Same on windows with Python 2.4. I think this is a Python 2.4 to Python 2.5 migration issue and not platform dependent. Are you using Python 2.4? Sure. If someone made Python 2.4 incompatible changes then they have to reverted :- [EMAIL PROTECTED] neither compiles directly using python setup.py build - neither with Python 2.4 nor 2.5 nor 2.6. Also running the bootstrap.py; bin/buildout dance does not work in any way...wtf??? Works here with Python 2.4, 2.5 and 2.6: [EMAIL PROTECTED]:~$ cd temp [EMAIL PROTECTED]:~/temp$ svn co $z/zope.app.container/trunk zope.app.container ... Checked out revision 92387. [EMAIL PROTECTED]:~/temp$ cd zope.app.container [EMAIL PROTECTED]:~/temp/zope.app.container$ python2.4 setup.py build running build running build_py ... running egg_info ... running build_ext building 'zope.app.container._zope_app_container_contained' extension creating build/temp.macosx-10.3-i386-2.4 creating build/temp.macosx-10.3-i386-2.4/src creating build/temp.macosx-10.3-i386-2.4/src/zope creating build/temp.macosx-10.3-i386-2.4/src/zope/app creating build/temp.macosx-10.3-i386-2.4/src/zope/app/container gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Iinclude -I/Users/philipp/include/python2.4 -c src/zope/app/container/_zope_app_container_contained.c -o build/temp.macosx-10.3-i386-2.4/src/zope/app/container/_zope_app_container_contained.o gcc -I/opt/local/include -L/opt/local/lib -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.4/src/zope/app/container/_zope_app_container_contained.o -o build/lib.macosx-10.3-i386-2.4/zope/app/container/_zope_app_container_contained.so [EMAIL PROTECTED]:~/temp/zope.app.container$ python2.5 setup.py build running build running build_py ... running egg_info ... running build_ext building 'zope.app.container._zope_app_container_contained' extension creating build/temp.macosx-10.3-i386-2.5 creating build/temp.macosx-10.3-i386-2.5/src creating build/temp.macosx-10.3-i386-2.5/src/zope creating build/temp.macosx-10.3-i386-2.5/src/zope/app creating build/temp.macosx-10.3-i386-2.5/src/zope/app/container gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iinclude -I/opt/include/python2.5 -c src/zope/app/container/_zope_app_container_contained.c -o build/temp.macosx-10.3-i386-2.5/src/zope/app/container/_zope_app_container_contained.o gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/src/zope/app/container/_zope_app_container_contained.o -o build/lib.macosx-10.3-i386-2.5/zope/app/container/_zope_app_container_contained.so [EMAIL PROTECTED]:~/temp/zope.app.container$ python2.6 setup.py build running build running build_py ... running egg_info ... running build_ext building 'zope.app.container._zope_app_container_contained' extension creating build/temp.macosx-10.3-i386-2.6 creating build/temp.macosx-10.3-i386-2.6/src creating build/temp.macosx-10.3-i386-2.6/src/zope creating build/temp.macosx-10.3-i386-2.6/src/zope/app creating build/temp.macosx-10.3-i386-2.6/src/zope/app/container gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iinclude -I/opt/include/python2.6 -c src/zope/app/container/_zope_app_container_contained.c -o build/temp.macosx-10.3-i386-2.6/src/zope/app/container/_zope_app_container_contained.o gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.6/src/zope/app/container/_zope_app_container_contained.o -o build/lib.macosx-10.3-i386-2.6/zope/app/container/_zope_app_container_contained.so [EMAIL PROTECTED]:~/temp/zope.app.container$ python2.4 bootstrap.py Creating directory '/Users/philipp/temp/zope.app.container/bin'. Creating directory '/Users/philipp/temp/zope.app.container/parts'. Creating directory '/Users/philipp/temp/zope.app.container/develop-eggs'. Generated script '/Users/philipp/temp/zope.app.container/bin/buildout'. [EMAIL PROTECTED]:~/temp/zope.app.container$ bin/buildout Develop: '/Users/philipp/temp/zope.app.container/.' Installing test. Generated script '/Users/philipp/temp/zope.app.container/bin/test'. [EMAIL PROTECTED]:~/temp/zope.app.container$ bin/test Running zope.app.container.testing.AppContainerLayer tests: Set up zope.app.container.testing.AppContainerLayer in 10.527 seconds. Ran 15 tests with 0 failures and 0 errors in 1.326 seconds. Running zope.testing.testrunner.layer.UnitTests tests: Tear down zope.app.container.testing.AppContainerLayer in 0.001 seconds. Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Ran 242 tests with 0 failures and 0 errors in
Re: [Zope-dev] Need help - wrong hierarchy on svn.zope.org
kevin gill wrote: I need a little help. I checked two packages into svn.zope.org, but I have set up the hierarchy incorrectly. The packages are z3c.rotterdam and z3c.boston. The egg is in the base folder, rather than in 'trunk'. I would appreciate it if someone with administration access to the repository could fix the paths. You can easily do that yourself: svn mv $z/z3c.rotterdam $z/z3c.rotterdam-trunk svn mkdir $z/z3c.rotterdam svn mv $z/z3c.rotterdam-trunk $z/z3c.rotterdam/trunk and the same thing with z3c.boston. Note that the $z environment variable is defines as follows: export z=svn+ssh://svn.zope.org/repos/main or if your remote user name differs from the local one: export z=svn+ssh://[EMAIL PROTECTED]/repos/main ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.container won't compile
Andreas Jung wrote: A trunk checkout compiles cleanly on Python 2.4: Sidnei checked in a fix for this problem on Thursday. I assume this made it into zope.app.container 3.6.1 released on October 15th: http://pypi.python.org/pypi/zope.app.container So why won't this version build with Python 2.4? Sidnei fixed the 3.6.1 tag locally to build on Python 2.4. The fix hasn't made it into a release yet. So far I didn't want to create a release because I'm puzzled by the problem myself: zope.app.container 3.5.6 builds on Python 2.4 perfectly without Sidnei's fix. However, zope.app.container 3.6.x will only build on Python 2.4 *with* Sidnei's fix (which is available from trunk). Regarding their C code, the two branches seem to be identical as far as I can tell (for instance, compare 3.5.6 to 3.6.1). That's why I'm a bit puzzled. Perhaps somebody else can shed light on this. Of course, if everybody's just annoyed and wants to move on, I'll be happy to create another 3.6.2 release with Sidnei's fix in it. In addition this release has a source dist and two eggs (for 2.4 and 2.5). Wasn't there consensus to upload sdists only (except for Windows)? Right. I uploaded an sdist and Sidnei uploaded two binary eggs for Windows. Where's the problem? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] traversal: different with and without a request
El 17 Oct 2008, a las 10:37 , Christian Theune escribió: There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of traversal are intermingled is when ++namespaces+ + are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed. URL traversal makes use of zope.traversing though. Yes, but only in the special case of ++namespace++ traversal. This is what I said in the above paragraph already. zope.publisher itself doesn't depend on zope.traversing and the default publication implementation in zope.app.publication uses zope.traversing only for + +namespace++ names (see usage of zope.traversing.namespace.nsParse in zope .app.publication.publicationtraverse.PublicationTraverse.traverseName). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] traversal: different with and without a request
El 17 Oct 2008, a las 15:02 , Jim Fulton escribió: First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). Historical note. Until we decided to use the location framework and eschew traversal proxies, is was much more widely used. It would be nice to deprecate zope.traversing and fold it into zope.app.pagetemplate. +1 The request shouldn't really be necessary for this kind of path resolution, I think. It's needed for looking up views and resources, both of which are commonly looked up in ZPT. Yeah, I forgot about that. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture. shrug / I'll note that the fix, in the context of ZPT is to always to a multi-adapter lookup using the request. Right. I'm fine with it always being a multi-adapter look-up. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
Hanno Schlichting wrote: Stephan Richter wrote: On Wednesday 15 October 2008, Sidnei da Silva wrote: I don't want to rain on your parade, but I already did a first pass at reviewing the changes in Python 2.5 and Python 2.6. There are no significant changes that I could spot so far. Apparently the major changes are: I also did a review for Python 2.5 a while ago... So does this mean RestrictedPython just had a bad emotional status in the community, but it is actually well proven and reviewed now? It has been reviewed by Jim for Python 2.4. When he did this, he wrote notes.txt which gives you a quick overview over the internals. The GSoC-sponsored efforts to port Zope 3 and Zope 2 to Python 2.5 included a review of RestrictedPython as well. As far as I can tell, the only changes to RestrictedPython were made by Sidnei a couple of days ago when he fixed it up for the new keywords in Python 2.6 and added some tests for features new in Python 2.5 and 2.6. I always was under the impression that Jim feared the code and the required security audit was perceived as a major painful undertaking. It's certainly something that should be undertaken carefully. New syntactical features (such as the =+ operator in the past, or the 'with' statement or inplace 'if' now) have to be analyzed with respect to their bytecode. Bytecode changes have to be tracked as well. It looks like Sidnei is on top of that already, though, which is certainly great to hear! Go Sidnei! :) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] traversal: different with and without a request
Christian Theune wrote: we stumbled over an annoyance that took a while to debug: Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test. In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not. We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent. zope.traversing is a mess. First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture. There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of traversal are intermingled is when ++namespaces++ are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed. I'm not sure my explanation are helpful ;). Did I mention it was a mess? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
Thomas Lotze wrote: Jim Fulton [EMAIL PROTECTED] wrote: I would change it to just use getattr rather than hasattr. try: getattr(ob, name) except AttributeError: return False ... This doesn't handle the case that the attribute exists as a property but raises an AttributeError when trying to produce its value. Yes, but this is still better than hasattr() which eats all exceptions. I think eating AttributeErrors is fine because to the user of 'ob', it would seem that ob.attr wouldn't exist anyway if it threw an AttributeError (even if that exception was about something else, it's still an AttributeError). I suggest doing marker = object() return getattr(ob, name, marker) is marker rather than return hasattr(ob, name) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] traversal: different with and without a request
El 15 Oct 2008, a las 19:24 , Shane Hathaway escribió: Philipp von Weitershausen wrote: First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture. There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of traversal are intermingled is when ++namespaces+ + are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed. I'm not sure my explanation are helpful ;). Did I mention it was a mess? This is very useful information that would have saved me a lot of confusion years ago. Is this written somewhere permanent, at least? Not that I know of. The documentation of zope.traversing would probably be a good place to put it. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] [Off-Topic] KSS ugly?
Encolpe Degoute wrote: Dieter Maurer a écrit : Garito wrote at 2008-10-8 14:22 +0200: I'm agree with you, Tino. Plone has a lot of ugly features (as KSS, for instance) Why is KSS ugly? Reading the documentation, I found it quite attractive That is what KSS opponents atr thinking: http://svn.plone.org/svn/collective/collective.kss.fucker/trunk/README.txt This document provides as little substance as much as it manages to insult the authors of KSS. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope 2.x for Py 2.6 as 64 bit Windows application?
[EMAIL PROTECTED] wrote: We're contemplating the move of our Zope 2.x application to 64-bit Windows. We rely on a few add-on packages, notably PyWin, which has 64-bit support for Py 2.6 only. I'd be grateful for a rough idea on when there could be a Zope 2.x release working with Python 2.6 as a 64-bit Windows application. We have no roadmap for this. Currently Zope doesn't run on Python 2.5 yet as Chris pointed out. That said, the GSoC porting project has made progress on the gsoc-python-2.5 branch and I think it runs Python 2.5 without any problems (but I might be wrong). Furthermore, Sidnei got this branch running on Python 2.6 now, albeit in an experimental status. If you have the need for this stuff to land, it would be a good idea to help out Sidnei and his crew. I have no idea what's holding up the Python 2.5 work to land, certainly it can't be that much more work to make it ready for trunk. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] Python 2.6: 'with' in Interfaces
Marius Gedminas wrote: On Wed, Oct 08, 2008 at 12:35:39AM -0300, Sidnei da Silva wrote: Trying to run some tests with Python 2.6 I stumbled on a problem that I need help with: an interface that has an attribute named 'with'. The interface in question is defined in zope.app.component.back35: class IAdapterRegistration(IComponentRegistration): ... with = schema.Tuple( title = _(With interfaces), ... Any suggestions on how to fix this one? The backwards-compatibility interfaces are supposed to expire after 3 releases (or was it years?), maybe we can simply remove this one? +1. The deprecation message says it's going away in Zope 3.5, so I suggest ripping all this stuff out on the trunk of zope.app.component and creating a new major release (which would then be Python 2.6 compatible). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Relative Imports: PEP-328
El 8 Oct 2008, a las 14:23 , Sidnei da Silva escribió: On Wed, Oct 8, 2008 at 8:53 AM, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Sidnei da Silva wrote: I'm trying to fix some import errors, which seem to be related to PEP-328. I'm fixing those errors this way, though I don't know if that's the recommended way of fixing it. Thoughts? try: from DT_Util import parse_params, name_param except ImportError: # See PEP-328 from .DT_Util import parse_params, name_param This will generate a SyntaxError in Python 2.4. So unless we *require* Python = 2.5, this won't work. Yuck. I hadn't thought of that. Any other suggestions? Like, using zope.documenttemplate? :) zope.documenttemplate is a crippled version of DocumentTemplate. It doesn't have all features (e.g. it lacks the C extension module) and hasn't been kept up-to-date with respect to bugfixes. So it seems like a good idea to put this clone out of its misery and retire it. I ultimately suggest going to absolute imports everywhere (at least as long as we have to maintain Python 2.4 compatibility). I realize that DocumentTemplate/DocumentTemplate.py creates a problem. So here's what I suggest: 1. Rename DocumentTemplate/DocumentTemplate.py to, say, DocumentTemplate/DocTemplate.py (feel free to come up with a better name) 2. Introduce absolute imports to DocumentTemplate.DocTemplate everywhere 3. Ensure backwards compatibility by adding the following lines to DocumentTemplate/__init__.py:: import DocumentTemplate.DocTemplate import sys sys.modules['DocumentTemplate.DocumentTemplate'] = DocumentTemplate.DocTemplate I *think* this should work. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Relative Imports: PEP-328
Sidnei da Silva wrote: I'm trying to fix some import errors, which seem to be related to PEP-328. I'm fixing those errors this way, though I don't know if that's the recommended way of fixing it. Thoughts? try: from DT_Util import parse_params, name_param except ImportError: # See PEP-328 from .DT_Util import parse_params, name_param This will generate a SyntaxError in Python 2.4. So unless we *require* Python = 2.5, this won't work. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: adding support for testing from bare setuptools
Marius Gedminas wrote: On Wed, Sep 17, 2008 at 12:52:49PM -0400, Tres Seaver wrote: Proposal Instead, what I *am* proposing is adding metadata which allows consumers of such packages to verify that the package is downloaded / installed correctly. In particular, I want for the following scenario to work seamlessly:: $ /path/to/virtualenv --no-site-packges sandbox ... $ cd sandbox $ tar xzf zope.foo.bar-3.5.6.tar.gz $ cd zope.foo.bar-3.5.6 # [1] $ ../bin/python setup.py test # [2] # Runs egg_info, installs regular and testing dependencies, and # runs all unit (non-layer) tests I don't like the idea that running the tests installs additional packages into my environment without me explicitly asking for it. You *are* asking for it by running python setup.py test. Also, python setup.py test doesn't actually install testing dependencies (or any dependencies for that matter) into site-packages. It just dumps them into the CWD. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
El 9 Sep 2008, a las 20:37 , Dieter Maurer escribió: Chris Withers wrote at 2008-9-8 18:34 +0100: ... There's the backward-compatibility issue, which is a showstopper. There's plenty of code that does this: adapter = package.interfaces.IFoo(object, None) Changing the signature as you describe would break all code that does this. How about a new major revision of zope.interface then? I fear that would be a bit drastic -- for a mostly cosmetic change. I agree. But interfaces might grow an additional method, e.g. adapt, which could get the new signature. The syntax would be a bit more cumbersome -- but on the other hand, it would be more explicit :-) I don't think it would be too cumbersome. While IMHO elegant, the current syntax of calling an interface to adapt isn't actually self- explanatory. I've frequently observed people tripping over this, specially when you have an IFoo interface and a Foo class -- which is quite common --, then IFoo(obj) and Foo(obj) differ only by one character. With your suggestion, it would be IFoo.adapt(obj) vs. Foo(obj), making the difference quite obvious. So overall I'm +1 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies and future of zope 3
Benji York wrote: On Wed, Sep 3, 2008 at 11:41 AM, Stephan Richter [EMAIL PROTECTED] wrote: For several packages we took the following approach. Most packages that have browser packages are in zope.app; for example, zope.app.folder (we did not convert this package yet). We then took the API and moved it to zope.folder. Maybe we should create a new namespace package for browser code. How about zope.browser? -0 My general sentiment is against creating more structure than we already have. Flat is better than nested. IMHO it's perfectly ok to have the Python APIs in zope.foo and browser code in zope.app.foo. I think sooner than later people won't want to the zope.app.* stuff anyway. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
El 30 Aug 2008, a las 07:50 , Dieter Maurer escribió:
Chris Withers wrote at 2008-8-29 10:25 +0100:
Dieter Maurer wrote:
Then, we could get rid of the {get|query}[Multi]Adapter altogether
and consistently use I() with appropriate optional
parameters --
what a simplification and homogenization :-)
Yeah, but since when has simplification or homogenisation been a
goal of
Zope 3? ;-)
It was with the Service geddon: make Service and Utility
homgogenous.
Indeed.
I've personally thought for some time that it would be quite nice if
all you had to do was call an interface to look up a utility (which is
sort of a multi-adapter of order 0) or to do some kind of adaption, no
matter how many objects you wanted to adapt. E.g.:
auth = IAuthentication() # utility
auth = IAuthentication(default=None)
langs = IUserPreferredLanguages(request) # adapter
langs = IUserPreferredLanguages(request, default=None)
view = IBrowserPage((obj, request), name='index')# named
multi-adapter
etc.
Personally I would favour such consistency higher than the current
behaviour, which may have been invented intentionally but still causes
confusion once in a while.
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
El 1 Sep 2008, a las 17:23 , Chris Withers escribió: Philipp von Weitershausen wrote: I've personally thought for some time that it would be quite nice if all you had to do was call an interface to look up a utility (which is sort of a multi-adapter of order 0) or to do some kind of adaption, no matter how many objects you wanted to adapt. E.g.: +sys.maxint. This is nice. auth = IAuthentication() # utility auth = IAuthentication(default=None) langs = IUserPreferredLanguages(request) # adapter langs = IUserPreferredLanguages(request, default=None) view = IBrowserPage((obj, request), name='index')# named multi-adapter Right, but how do you differentiate adapting a tuple to IBrowserPage versus adapting obj and request together to IBrowserPage? You don't, I guess. I'd say that multi-adaption is *defined* as the adaption of a tuple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
El 1 Sep 2008, a las 19:26 , Dieter Maurer escribió: Chris Withers wrote at 2008-9-1 16:23 +0100: ... auth = IAuthentication() # utility auth = IAuthentication(default=None) langs = IUserPreferredLanguages(request) # adapter langs = IUserPreferredLanguages(request, default=None) view = IBrowserPage((obj, request), name='index')# named multi-adapter Right, but how do you differentiate adapting a tuple to IBrowserPage versus adapting obj and request together to IBrowserPage? One way would be to use *objs in the Interface.__call__ signature. Then, multi-adaptation could be I(obj1, obj2, ...) and tuple adaptation I((obj1, obj2, ...)). Of course, all other parameters would need to be keyword parameters (a good thing). Do you have a serious use case for tuple adaptation? IIRC, the twisted guys do. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser.testing.Browser has undefined dependencies
Chris Withers wrote: I'm just starting to play with zope.testbrowser's testing.Browser but I notice that is uses the following packages: transaction zope.app.testing zope.app.folder zope.app.component ...but zope.testbrowser doesn't declare any dependency on these. It does, using the extras mechanism you mention below. It probably should in some way, but I can see why it doesn't currently, give nthat there are likely lots of zope.testbrowser users who have to interested in zope.testbrowser.testing.Browser. Is this something that we can solve with: http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras-optional-features-with-their-own-dependencies If it is, I guess we would add an extra_requires to zoep.testbrowser's setup.py with the packages listed above? If you had a look at zope.testbrowser/setup.py, you'd notice extras_require = dict( test = ['zope.interface', 'zope.schema', 'zope.app.component', 'zope.app.folder', 'zope.app.testing', 'zope.app.zcmlfiles', 'zope.app.securitypolicy', ], ), Would the following then work in a buildout: [test] recipe = zc.recipe.testrunner eggs = mypackage zope.testbrowser[testing.Browser] zope.testbrowser [test] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZODB3 3.9.0-dev-r77011 egg?!
Chris Withers wrote: Why does the egg in the subject line exist Because somebody made it and uploaded it to download.zope.org. It probably happened during the initial eggification period when we didn't have a solid release process [1]. and why does buildout pick it over a stable release? Because buildout, like easy_install, will pick the newest available version for a distribution. Fortunately, buildout has a prefer-stable option so that you can tell it to prefer stable over alpha/beta/dev releases. Also, in any serious situtation you'd want to pin your versions, e.g. using the KGS [2] or a manual list. [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt [2] http://download.zope.org/zope3.4/versions.cfg ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [zopeproject] ZODB3 specified, but ZODB3 3.9.0-dev-r77011 egg still attempted?!
Chris Withers wrote: Okay, So I bumped into the ZODB3 3.9.0-dev-r77011 problem while trying to get going with zopeproject. zopeproject created a buildout.cfg in my test project, so I thought I'd lock ZODB to 3.8.0 to prevent problems: [buildout] develop = . parts = app test find-links = http://download.zope.org/distribution/ newest = false eggs-directory = C:\Zope\buildout-eggs [app] recipe = zc.recipe.egg eggs = HelloWorld zope.app.apidoc zope.app.securitypolicy z3c.evalexception=2.0 Paste PasteScript PasteDeploy interpreter = python [versions] ZODB3 = 3.8.0 [test] recipe = zc.recipe.testrunner eggs = HelloWorld defaults = ['--tests-pattern', '^f?tests$', '-v'] This didn't work, buildout still tries to install 3.9.0-dev-r77011. Why?! Because you're not doing it right. You invented a [versions] section but you still need to tell buildout to actually use that section as a versions declarations: [buildout] ... versions = versions http://pypi.python.org/pypi/zc.buildout#repeatable-buildouts-controlling-eggs-used I also noticed that buildout from this .cfg doesn't seem to use the latest versions of things. It's only using version 1.0.7 of zc.buildout, not the 1.1.0 I'd expect. Because it's running in non-newest mode (newest = false in [buildout]). bin/buildout -n will override that setting from the command line and run it in newest mode. http://pypi.python.org/pypi/zc.buildout#newest-and-offline-modes Now, my understanding is that find-links adds to the index rather than replaces it, so what's going on here? This has nothing to do with it. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZODB3 3.9.0-dev-r77011 egg?!
El 19 Aug 2008, a las 12:05 , Chris Withers escribió: Philipp von Weitershausen wrote: and why does buildout pick it over a stable release? Because buildout, like easy_install, will pick the newest available version for a distribution. Fortunately, buildout has a prefer- stable option so that you can tell it to prefer stable over alpha/ beta/dev releases. Also, in any serious situtation you'd want to pin your versions, e.g. using the KGS [2] or a manual list. Okay, so how come zopeproject doesn't do any of these? Because I haven't bothered to update it yet. I don't even know how to use the KGS - where would I find docs on that? It's just the standard buildout-extension feature that you can use to pull in a versions list from the web, e.g. the one I just pasted you in my previous email: [buildout] ... extends = http://download.zope.org/zope3.4/versions.cfg versions = versions See http://pypi.python.org/pypi/zc.buildout#multiple-configuration- files. Of course you could also just download the file and add it to your buildout.cfg verbatimly. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Shane Hathaway wrote:
Chris Withers wrote:
From a user's perspective, this makes no sense:
from zope.interface import implements,Interface
from zope.component import queryAdapter
class ISomething(Interface): pass
...
class MyClass: implements(ISomething)
...
m = MyClass()
Right, so this does make sense:
ISomething(m)
__main__.MyClass instance at 0x00BED6E8
This does not:
repr(queryAdapter(m,ISomething))
'None'
Looks like a bug to me. If the object passed as the first argument to
queryAdapter() implements the interface passed as the second argument, I
believe queryAdapter() should return the object, regardless of any
component registrations.
No, it's not a bug. This is in fact a feature (like it or not).
{query|get}Adapter will always try to look up an adapter, whether or not
the object provides the interface. So the behaviour Chris observed is
indeed intended. I agree it could be documented better.
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 4 OK, 1 Unknown
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zope Tests Summarizer wrote: Summary of messages to the zope-tests list. Period Fri Aug 15 11:00:00 2008 UTC to Sat Aug 16 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Unknown --- Subject: UNKNOWN : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Fri Aug 15 20:40:07 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010015.html I can't reproduce this failure on my box (self-compiled Python 2.3.5, Ubuntu). Does anyone have a clue why the 'encodings.aliases' module would be different? I certainly don't, but apparently there was a bug report [1] which caused Andreas to fix it in Hotfix (see r89881), but not the Zope 2.8 branch. [1] https://bugs.edge.launchpad.net/zope2/+bug/258154 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PythonScripts/PythonScript.py Merge Maurits's r89745 as well: Proper English spelling of cannot.
Log message for revision 89760:
Merge Maurits's r89745 as well: Proper English spelling of cannot.
Changed:
U Zope/trunk/lib/python/Products/PythonScripts/PythonScript.py
-=-
Modified: Zope/trunk/lib/python/Products/PythonScripts/PythonScript.py
===
--- Zope/trunk/lib/python/Products/PythonScripts/PythonScript.py
2008-08-12 22:26:28 UTC (rev 89759)
+++ Zope/trunk/lib/python/Products/PythonScripts/PythonScript.py
2008-08-12 22:48:42 UTC (rev 89760)
@@ -325,7 +325,7 @@
try:
result = f(*args, **kw)
except SystemExit:
-raise ValueError('SystemExit can not be raised within a
PythonScript')
+raise ValueError('SystemExit cannot be raised within a
PythonScript')
if keyset is not None:
# Store the result in the cache.
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] zope.app.form: Make no value always available?
Thomas Lotze wrote: zope.app.form items edit widgets don't provide the no value value if the corresponding field is required. While this prevents invalid input, it means that e.g. a drop-down box may then have one of the valid values pre-selected. If user forgets to change that value, he could save the form without noticing that the default value is implicitly selected, which may be completely wrong. In some cases it would be preferrable for the widget to default to a no value value even if the field is required so the form won't validate if the user doesn't consciously select a value. One of our customers asked for this behaviour, for example. If noone objects, we'd like to change zope.app.form accordingly. +1, but perhaps for required fields we shouldn't say (no value), we should say (select a value). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope] Re: Page Template help
Garito wrote: Could someone point me where the page template code decide if an expression is a path expression or a string or python one, please? I'm studying the zope page template classes and I would like to understand where this decision is taken Products.PageTemplates.Expressions.createZopeEngine(): for pt in ZopePathExpr._default_type_names: e.registerType(pt, ZopePathExpr) ZopePathExpr._default_type_names contains, among others, the name 'standard', which makes this expression type the default expression type. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Page Template help
Garito wrote:
Use:
/path/to/the/object/with/${some/magic/variables}/to/solve/some/paths/in/a/simplest/way
Path expressions already support this.
tal:define=pathel some/magic/variables;
objpath/to/the/object/with/?pathel/to/solve/some/...
So basically in TALES path expressions you can say foo/?bar and the
value of the 'bar' variable will be used to traverse the next step from
'foo'.
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Page Template help
Garito wrote:
Considere this case:
I have the sking value in the variable at args/Yanged/Skin
How can I do the equivalent to
args/Yanged/raiz/Skins/${args/Yanged/Skin}/arbolYanged.css/absolute_url
?
In the python way it will be:
path(path('string:' +
'args/Yanged/raiz/Skins/${args/Yanged/Skin}/arbolYanged.css/absolute_url'))
That's returns the expected value but I can't see how to do with your
propossed way
a tal:define=skin args/Yanged/Skin;
file args/Yanged/raiz/Skins/?skin/arbolYanged.css
tal:attributes=href file/absolute_url
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Page Template help
Garito wrote: Finally it's possible to do what I need without the need to declare any variable? Not that I know of. If not my change will be 4-6 lines of code and it's ok for me to make this change I only need to understand were the code decides if the expression is standard, string or python I already pointed you to the code where the different expression types are registered. From there you should be able to deduce where these registrations are used. I don't know this by heart and would have to search for myself. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Disable configuration of 3rd party packages with z3c.unconfigure
When relying on a third-party package with ZCML configuration, it is sometimes desirable to disable certain directives, for instance when the third-party package defines an event subscriber that you'd like to disable. This is now possible with z3c.unconfigure. While zope.configuration (the package that implements ZCML) itself supports overriding existing configuration and the zc.configuration package supports excluding whole ZCML files from being loaded, z3c.unconfigure allows you to disable specific directives. More information is available at http://pypi.python.org/pypi/z3c.unconfigure. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: zope.app.authentication and zope.app.container broken doctests
Wichert Akkerman wrote: I've re-tagged and reuploaded new versions zope.app.container 3.5.6 and zope.app.authentication 3.4.3. This should be ok. Re-uploading is very problematic: if anyone has the previous version in their buildout download cache they will never get the new version. I prefer a minor version number bump instead of re-uploading. That's what Christophe did. His choice of words is just a bit confusing. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zcml filtering
Marius Gedminas wrote: On Tue, Aug 05, 2008 at 10:36:30PM +0100, Martin Aspeli wrote: Subscribers and subscription adapters are particularly bad in this way, since they are unnamed and thus can't be overridden, only amended to. We've talked about an off switch for ZCML before. Given that we have a configuration machine that's capable of doing overrides based on discriminators, why couldn't we have support for negatives, e.g. unconfigure utility ... / /unconfigure This could use a special _context that would record callables and discriminators, and then look for the corresponding callables/discriminators in the real context and remove them before that context was configured. Subscribers don't have discriminators, unfortunately. Indeed they don't. That just makes them harder to track down, though. I'm working on a package for this functionality in z3c.unconfigure right now. Name inspired by Martin's suggestion above; my original prototype used had a different name but this is much better :). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zcml filtering
El 6 Aug 2008, a las 16:47 , Stephan Richter escribió: On Wednesday 06 August 2008, Philipp von Weitershausen wrote: I'm working on a package for this functionality in z3c.unconfigure right now. Name inspired by Martin's suggestion above; my original prototype used had a different name but this is much better :). Couldn't we just merge zc.configuration and z3c.unconfigure into zope.configuration? Everyone who wants to use our configuration system certainly wants this functionality as well. I'm +1 on zc.configuration. z3c.unconfigure, however, will contain zope.component specific code to unconfigure subscribers (which currently have no useful discriminator). So it's a hack to make it work with existing Zope code out there. If zope.component.zcml were changed to emit useful actions for subscriber / (and interface /, too!), we could solely rely on shooting down actions and the code could find its way into zope.configuration. That will only help us with future Zope code, not with existing code out there (which this is for). Feel free to undertake this :) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zcml filtering
El 6 Aug 2008, a las 17:17 , Roger Ineichen escribió: I'm +1 on zc.configuration. z3c.unconfigure, however, will contain zope.component specific code to unconfigure subscribers (which currently have no useful discriminator). So it's a hack to make it work with existing Zope code out there. If zope.component.zcml were changed to emit useful actions for subscriber / (and interface /, too!), we could solely rely on shooting down actions and the code could find its way into zope.configuration. That will only help us with future Zope code, not with existing code out there (which this is for). Feel free to undertake this :) That's a good argument but valid for any development or improvment on existing code/packages. It's about being pragmatic. We need to this to work on existing code (Zope 3.3 to be exact). We can't just upgrade zope.configuration. The bad thing is that we now have 3 packages for one thing doing right. It's unfortunate, but things could be worse. I'm +1 too for a simple zope.configuration package which offers the API for doing configuration how it should. What do you think about to release z3c.unconfigure and merge it to zope.configuration after the release. So we have both options and a simple setup for the future. Not forgetting to give subscriber / and interface / decent discriminators. But yes, that sounds like a great idea. Feel free to do it ;). I probably won't have time to worry about this any time soon. I'm just trying to fix an issue at hand. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: configuring global utilities in zcml
Chris Withers wrote: Nikolay Kim wrote: you can create utility in python file and then use component= for example utility.py: class Utility(object): pass myUtility = Utility() configure.zcml: utility name=myUtility component=.utility.myUtility / I'm aware of this but it kind of defeats the idea of seperating code and configuration... What kind of configuration are we talking about here? I personally think that ZCML is great for switching on and off software components and then perhaps configuring a few software-related aspects about them (e.g. security protections). But IMHO ZCML is the wrong tool to configure, say, database connections or SMTP server settings for outgoing email. Because this isn't configuring software, it's configuring settings *for* software. I personally therefore prefer to make settings like those configurable a) either in zope.conf (there's an easy way to have to custom settings in zope.conf read by your utilities, see zope.app.appsetup.product b) or TTW by implementing the utility in question as a local utility and then writing browser pages for it. I'm all for separating code and configuration, but I'm also all for separating admin configuration from developer configuration. I don't think an admin should ever have to edit ZCML (and yes, I do realize that this wasn't the initial vision, but let's face it, ZCML is a developer tool). Or, if I take Grok: the developer writes Python, the admin writes some other form of configuration, be it zope.conf, paste.ini or TTW configuration in a browser. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: configuring global utilities in zcml
Chris Withers wrote: Nikolay Kim wrote: I'm aware of this but it kind of defeats the idea of seperating code and configuration... So, other ideas? create new zcml directive. That seems pretty heavyweight :-/ It's not. It's in fact relatively easy to write a custom utility directive that takes arbitrary parameters and then passes them on to the utility's factory. The question is whether that's a good idea. I don't think it is. Either the parameters you want to pass have to do with code, then ZCML isn't the right *tool* because from ZCML you can only pass Unicode strings (for arbitrary parameters, ZCML can't do its magic of resolving dotted names or validating or whatever). Or the parameters you want to pass have to do with configuration (e.g. some server name, a port, a directory, etc.). Then ZCML isn't the right *place*. An admin-friendy place (zope.conf, paste.ini, custom configuration file, etc.) would be a much better place. Or make it a local persistent utility that stores its configuration persistently and allows it to be changed TTW. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Please no version numbers in setup.py [was: SVN: Zope2.buildout/tags/2.11.1/setup.py Pin / fix up dependencies based on comparison with monolith.]
Tres Seaver wrote: Log message for revision 89399: Pin / fix up dependencies based on comparison with monolith. Thanks for picking this up! I do, however, strongly object to pinning versions of dependencies in setup.py like this. What's the point of eggifying Zope 2 in the first place then if not for the ability to upgrade individual libraries to newer versions with bugfixes or features? Instead of pinning versions in setup.py, we should rather include a list of known-good versions, or even better, add the Zope 2 eggs to the Zope KGS. That way, by default, you'd get the known good set but you could deviate from it as necessary. More importantly, by having one good set (instead of a setup.py here, a versions.cfg there and another list somewhere else), the KGS becomes much easier to maintain. Philipp + install_requires=['Acquisition==2.11.1', +'DateTime==2.11.1', +'docutils==0.4.0', +'ExtensionClass==2.11.1', +'Interface==2.11.1', +'Persistence==2.11.1', +'pytz==2007f', # latest is fine? +'RestrictedPython==3.4.2', +'StructuredText==2.11.1', +'tempstorage==2.11.1', +'ZConfig==2.5.1', +'zLOG==2.11.1', +'zdaemon==2.0.1', +'ZODB3==3.8.0', +'zodbcode==3.4.0', +'zope.annotation==3.4.0', +'zope.cachedescriptors==3.4.0', +'zope.component==3.4.0', +'zope.configuration==3.4.0', +'zope.contentprovider==3.4.0', +'zope.contenttype==3.4.0', +'zope.copypastemove==3.4.0', +'zope.datetime==3.4.0', +'zope.decorator==3.4.0', +'zope.deferredimport==3.4.0', +'zope.deprecation==3.4.0', +'zope.documenttemplate==3.4.0', +'zope.dottedname==3.4.0', +'zope.dublincore==3.4.0', +'zope.error==3.5.1', +'zope.event==3.4.0', +'zope.exceptions==3.4.0', +'zope.filerepresentation==3.4.0', +'zope.formlib==3.4.0', +'zope.hookable==3.4.0', +'zope.i18nmessageid==3.4.0', +'zope.i18n==3.4.0', +'zope.index==3.4.0', +'zope.interface==3.4.0', +'zope.lifecycleevent==3.4.0', +'zope.location==3.4.0', +'zope.minmax==3.4.0', +'zope.modulealias==3.4.0', +'zope.pagetemplate==3.4.0', +'zope.proxy==3.4.0', +'zope.publisher==3.4.0', +'zope.rdb==3.4.0', +'zope.schema==3.4.0', +'zope.security==3.4.0', +'zope.sequencesort==3.4.0', +'zope.sendmail==3.4.0', +'zope.server==3.4.0', +'zope.session==3.4.0', +'zope.size==3.4.0', +'zope.securitypolicy==3.4.0', +'zope.structuredtext==3.4.0', +'zope.tales==3.4.0', +'zope.tal==3.4.0', +'zope.testbrowser==3.4.0', +'zope.testing==3.4.0', +'zope.thread==3.4.0', +'zope.traversing==3.4.0', +'zope.viewlet==3.4.0', +'zope.wfmc==3.4.0', +'zope.app.annotation==3.4.0', +'zope.app.apidoc==3.4.3', +'zope.app.applicationcontrol==3.4.1', +'zope.app.appsetup==3.4.1', +'zope.app.authentication==3.4.1', +'zope.app.basicskin==3.4.0', +'zope.app.broken==3.4.0', +'zope.app.cache==3.4.0', +'zope.app.component==3.4.1', +'zope.app.container==3.5.3', +'zope.app.content==3.4.0', +#'zope.app.content_types==3.4.0', XXX +'zope.app.debug==3.4.0', +'zope.app.dependable==3.4.0', +'zope.app.error==3.5.1', +#'zope.app.event==3.4.0', XXX +'zope.app.exception==3.4.1', +'zope.app.file==3.4.2',
Re: [Zope-dev] Re: bad zope.size to remove from PyPI
El 2 Aug 2008, a las 17:45 , Chris Withers escribió: Benji York wrote: In case anybody's wondering how this complies with our no removal of any release whatsoever policy [1], be assured that a 3.4dev-r73090 thing isn't a release by our standards. This version number not only contains the 'dev' marker, meaning it must have come from a development branch (possibly the trunk), it also contains the -rXXX suffix meaning it was made right from a subversion checkout without having created a tags first (why else would you want to include the revision number). Still, it's likely that someone was using it and their buildouts are now broken. We should have instead generated a proper release with a higher version number and left the dev release alone. This is silly. Mistakes happen. Buildout and/or setuptools should be tolerant of accidental releases that are then removed from PyPI. What currently happens in cases like this? Nothing. It's only a problem if somebody pinned zope.size version to 3.4dev-r73090 in their buildout.cfg. But that's their own fault IMHO because it's clearly not a release.___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: bad zope.size to remove from PyPI
Christophe Combelles wrote: could someone remove this package from the PyPI : http://pypi.python.org/pypi/zope.size/3.4dev-r73090 This is an empty development version, considered more recent by PyPI than the latest released version 3.4.0. (which is r78211) Done. In case anybody's wondering how this complies with our no removal of any release whatsoever policy [1], be assured that a 3.4dev-r73090 thing isn't a release by our standards. This version number not only contains the 'dev' marker, meaning it must have come from a development branch (possibly the trunk), it also contains the -rXXX suffix meaning it was made right from a subversion checkout without having created a tags first (why else would you want to include the revision number). [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: zope.release/branches/3.4/ * Added latest version of zope.app.security to avoid deprecation
Christophe Combelles wrote: Stephan Richter a écrit : On Friday 01 August 2008, Christophe Combelles wrote: Did you miss the CHANGES.txt in zope.release ? We have two histories now. Nope, but that file tracks the package -- source code -- changes of zope.release. I wanted a separate file that tracks the changes to the controlled-packages.cfg file. In my understanding, there is almost no source code in 'zope.release', since it has been moved into 'zope.kgs'. So there should be very few entries in CHANGES.txt, and I'm not sure there is a real interest in having two separate files. In my opinion, it adds confusion, people are more used to maintain CHANGES.txt. Exactly. The other problem is there is no tag for c1, c2, c3 and c4. I thought zope.release was meant to represent the release number of zope. I would tend to: - create a tag for all missing candidates - merge KGS-HISTORY.txt into CHANGES.txt and recover missing information from published control-packages.cfg +1 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Running the 3.4 KGS tests: 9 fail, 6 errors
Shane Hathaway wrote: Marius Gedminas wrote: I think I'll run the test suite again on a 64-bit Linux machine, for extra fun. And maybe do that for Python 2.4 as well. zope.proxy and related modules failed badly under 64 bit Python 2.5 until I fixed the C code on the trunk 2 weeks ago, however, I don't think my changes landed in the KGS. I also fixed broken tests. Should I backport my changes? I don't know whether a release is planned soon. Hey Shane, thanks for those fixes! I've just made the necessary backports and tagged the following releases: zope.proxy 3.4.2 zope.security 3.4.1 zope.security 3.5.2 zope.app.container 3.5.5 I haven't uploaded them to PyPI yet because a) I don't have the rights to all of them and b) they have extension modules which means we should simultaneously release Win32 binaries (which I can't). I've therefore CC'ed Jim, hoping that he could upload the sdist tarballs and the binary eggs for Windows. Jim? Thanks, Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Utility factory handling for zope.component
Wichert Akkerman wrote: Stephan Richter wrote: On Wednesday 23 July 2008, Wichert Akkerman wrote: If there are no objections I intend to merge the branch to trunk in a few days I am uncomfortable with the way you approached this. I think there are at least two other possibilities that I can see without having looked closer: 1. Use the info object. The point of the info is to contain this sort of information. Which info object are you referring to? The only information I could see for utility registration is a tuple, not an object. This is used to build the UtilityRegistration object when querying registration information, and I added a factory method there. I think Stephan is referring to the (formerly) last item of the tuple, which is available as utility_reg.info. It contains information about how the component was registered, for instance the ZCML file name + line number. It looks like Stephan is suggesting to do something like this: component = factory() registry.registerUtility(component, info=InfoAbout(factory)) whereas Wichert's approach allows you to write: registry.registerUtility(factory=factory) I prefer Wichert's approach. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Please use 'svn mv'
I would like to remind everyone that when you do refactorings and move code around, to please use 'svn mv' or 'svn cp'. For instance, when you split a large file into two smaller ones, use 'svn cp' to create the second file and then remove stuff from it that doesn't go there. That way, version history isn't lost for neither parts of the code. The same goes for splitting up packages (moving components into a library package, for instance). Thanks. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: how many checkin lists?!
Chris Withers wrote: Hi All, Just me, or is it excessive that we have: http://mail.zope.org/pipermail/zope3-checkins/ This one is obsolete now. http://mail.zope.org/pipermail/zope-checkins/ This one is for Zope 2 only. http://mail.zope.org/pipermail/checkins/ This one covers the whole repository. ...and maybe more I don't know about? Surely one list would suffice? I think so. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond
Tres Seaver wrote: Mark Hammond wrote: Well, Zope moved onwards from PAS to PAU I doubt that seriously: I would venture that there are two orders of magnitude more users of PAS than PAU in production deployments. PAU was an attempt to port the PAS to a component-centric implementation, but it lost at least a couple of key features along the way: most notably, the ZCA provides no way to control the ordering of the invocation of the plugins. The ZCA may have no built-in way to control the ordering, but PAU surely does control the ordering. It keeps an ordered list of plugin names. These plugins can either be contained items in the PAU (like in PAS) or utilities for ICredentialsPlugin or IAuthenticatorPlugin. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: No events in zope.annotation
Stephan Richter wrote: Hi everyone, I just tried to create a catalog for an annotation and noticed that it does not get filled. Digging around in the zope.annotation package, I noticed that the zope.annotation package does not send out any object events. This sucks. ;-) Thus I propose: - Add ObjectCreatedEvent event notification to zope.annotation factory call. +0 - Add ObjectAddedEvent to attribute annotations __setitem__. - Add ObjectRemovedEvent to attribute annotations __delitem__. -1. As Fred said, these events are specific to containers (as in IContainer). IAnnotation adapters aren't containers and annotation objects aren't contained in them (as in IContained). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: No events in zope.annotation
Stephan Richter wrote: On Tuesday 15 July 2008, Fred Drake wrote: On Tue, Jul 15, 2008 at 12:30 PM, Stephan Richter [EMAIL PROTECTED] wrote: Thus I propose: - Add ObjectCreatedEvent event notification to zope.annotation factory call. By this, I presume you mean the stuff in zope.annotation.factory; is that right? Yes. In our group, we've decided to avoid that machinery. It causes the separation between data and code to become excessively blurred. I'd love to see that factory machinery become unused. I definitely consider it unusable. I use it all the time. I think it makes development a lot easier. I agree. In fact, this came out of the ST project, where we constantly repeated this sort of code. Not that it matters much, but I think it was Martijn Faassen who wrote it. BTW, I really do not understand how it blurs the separation of code and data. Me neither. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope] Re: Deployment Best Practices?
Jeff McNeil wrote: That's not all that obvious to someone new to the Zope system. Most of the documentation I've found is geared towards the 2.x branch. As Zope 3 and Zope 2 are different animals, I wouldn't think that the deployment steps and recommendations would be all that similar. With buildout, they can be similar, at least superficially. I really like what I've seen thus far, it's just been difficult at times as it feels like I'm fighting with documentation. So I'm assuming I'll just need to build up a Zeo server instance with zc.zodbrecipes and update my corresponding buildout.cfg for the Zope instances? Yep, you can do that. If Buildout is the preferred deployment tool, then my redistributable is a sandbox tarball or an RPM containing the skeleton files needed to bootstrap a buildout run on the target hosts? Yes. Maybe I'll dump the whole process on a blog somewhere as I step through it. That'd be cool! I do have another question. The project we're working on is plug-in based. Within the old system, eggs are loaded dynamically using setuptools pkg_resources and we define certain entry points for capability registration. Eggs are added to a directory and a config entry is made such that we can load the proper version of each plug-in. Is there an upfront way to reproduce that functionality without needing to update setup.py and rerun buildout every time we want to push a new plug-in or update an existing? Well, you could just do the exact same thing that you did in your old application, I suppose. I'd love to be able to just drop an egg on the file system and tell Zope Here, go load that one now via configuration alone. You could also write your own ZCML directive (+ a handler) that does that. Then you'd only ever have to change your application's site.zcml to load a new plugin. My apologies if some of this is obvious. As I said, I'm really just tackling Zope for the first time. Don't worry, your questions are valid. We haven't actually done a very good job of documenting things on the website. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Deployment Best Practices?
Paul Winkler wrote: On Sun, Jul 13, 2008 at 01:20:53PM -0400, Philipp von Weitershausen wrote: Jeff McNeil wrote: I'd love to be able to just drop an egg on the file system and tell Zope Here, go load that one now via configuration alone. You could also write your own ZCML directive (+ a handler) that does that. Then you'd only ever have to change your application's site.zcml to load a new plugin. There's also this: http://pypi.python.org/pypi/z3c.autoinclude Yep, that only saves you the include package=... / directive, though. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: Zope3 installation on windows - how?
Hermann Himmelbauer wrote: And there's once again this mingw32 problem. 4) Next, I tried zopeproject: $ easy_install zopeproject $ zopeproject HelloWorld First, zopeproject does not install the packages into the Python site-packages, That's *intended*. That's, in fact, much better than stuffing about a 100 eggs into site-packages... What can I do? Is there perhaps some precompiled Windows distribution for Zope-3.4 available? All Zope 3.4 packages that have C extensions are available as Windows binaries, though perhaps not in all versions. The versions in the KGS should all be available as Windows binaries, though. Just include http://download.zope.org/zope3.4/versions.cfg in your buildout.cfg. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond
Wichert Akkerman wrote: Previously Florian Friesdorf wrote: Hi *, within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages. All documents describing the project, as well as links to the code can be found here: https://chaoflow.net/projects/gsoc2008/z3membrane-ldap The one thing I am missing is: why? PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins. It's also perfectly possible to use non-AT content as source for users with PAS as well as tools such as b-org demonstrate. Exactly. I don't mean to pee on anybody's parade here, but IMHO Wichert is right. To be constructive, I think it'd be much more interesting to investigate hooking Plone up to an external authentication mechanism such as repoze.who. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PAULA: bringing Zope 3's authentication to Plone and beyond
Wichert Akkerman wrote: Previously Philipp von Weitershausen wrote: Wichert Akkerman wrote: Previously Florian Friesdorf wrote: Hi *, within the scope of google summer of code I am integrating zope 3's PAU with Plone's PAS and further enable (non-AT) content objects as source for users and groups. All functionality is developed in pure zope3, the plone integration is happening in a separate packages. All documents describing the project, as well as links to the code can be found here: https://chaoflow.net/projects/gsoc2008/z3membrane-ldap The one thing I am missing is: why? PAS works fine and covers a lot more functionality than PAU and there are more PAS plugins than PAU plugins. It's also perfectly possible to use non-AT content as source for users with PAS as well as tools such as b-org demonstrate. Exactly. I don't mean to pee on anybody's parade here, but IMHO Wichert is right. To be constructive, I think it'd be much more interesting to investigate hooking Plone up to an external authentication mechanism such as repoze.who. Doesn't repoze already have a PAS plugin to do just that? Ah, that's right: http://svn.agendaless.com/Products.whoopass. That doesn't mean it could be integrated better, though, for instance UI-wise... ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope] Re: I wonder why class constructor is never in apidoc ?
KLEIN Stéphane wrote: I wonder why class constructor is never in apidoc ? Because nobody has bothered to implement this feature. Patches are welcome :) Are there something in OOP concept I haven't understand ? I don't know what you mean with this. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] Re: buildout on Windows
El 21 Jun 2008, a las 20:15 , Chris Withers escribió: Philipp von Weitershausen wrote: This isn't a matter of a binary zope.proxy egg. If you look at the 'zope2' part of your buildout.cfg, you'll see it's actually trying to compile Zope 2 itself (which happens to contain the zope.proxy package as part of the Zope 3 libraries that it ships with). Right, this doesn't seem sane. Is this the fault of the recipe or of buildout? zc.buildout is a generic deployment tool. It's not related to Zope in any specific way (other than that it shares a couple of contributors). You can think of zc.buildout as 'make'. It just does what you tell it to do. buildout.cfg is the zc.buildout's Makefile. As I said, if you look at *your* specific buildout.cfg, you'll see that it tells zc.buildout to compile Zope 2. This is not a faulty zc.buildout presetting (because zc.buildout is a generic tool). What you want to do on Windows is install Zope 2 manually using the installers, then edit buildout.cfg to NOT build Zope 2, but to refer to the installation location, e.g.: Well, I really don't ;-) I want buildout to get binary eggs on windows Zope2 isn't eggified yet, so it can't be installed as eggs. or (and I know I'm asking a lot here) to get a binary Zope 2 if it needs one. Then you want to a) either write a recipe that does just that b) or extend the plone.recipe.zope2install recipe to get the binary Zope installer and execute it (if that's even possible) on Windows, rather than trying to get the source tarball and compile it (this would still be the default for Unixy platforms). Option b) is probably preferred because then you can share the same buildout.cfg between different platforms. I'm still hazy on what the problem is... Will buildout use binary eggs if they're available? (given that it's Windows where this is particularly important...) Yes, buildout just uses setuptools to fetch and install eggs. But as said, Zope 2 isn't eggified yet, so there's no point debating what kind of eggs it should have gotten. Your buildout.cfg never told it to get an egg. Your buildout.cfg tells it to compile and install Zope 2. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout on Windows
Martin Aspeli wrote: Chris Withers wrote: Hey All, I'm trying to run a plone-ish buildout on Windows for a customer, currently getting this: creating zope.proxy copying zope/proxy\proxy.h - zope.proxy error: Python was built with Visual Studio 2003; extensions must be built with a compiler than can generate compatible binaries. Visual Studio 2003 was not found on this system. If you have Cygwin installed, you can try compiling with MingW32, by passing -c mingw32 to setup.py. While: Installing zope2. Do binary eggs exist for zope.proxy and friends? If not, how do I build 'em and upload them for others to use? If they do exist, how do I get buildout to use them rather than trying to build from source on my system? buildout will use binary eggs if they exist and match the version spec, so you may want a [version] block. However: - if you really are installing zope2, then I wonder why it's trying to download zope.proxy. It's not, it's just compiling Zope 2 which contains zope.proxy. From my initial reply to Chris: This isn't a matter of a binary zope.proxy egg. If you look at the 'zope2' part of your buildout.cfg, you'll see it's actually trying to compile Zope 2 itself (which happens to contain the zope.proxy package as part of the Zope 3 libraries that it ships with). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: View component registration
Martijn Faassen wrote: One question is what to do for persistent registrations in local sites. I don't imagine they're used a lot, but it'd mean a content upgrade to re-register them, right? The only piece of software that, to my knowledge, can actually *make* local view registrations is five.customerize. Plone uses it to allow local customization of Zope 3 views and viewlets. I suppose they'll just have to write an upgrade script (after having update five.customerize itself). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout on Windows
Chris Withers wrote:
Hey All,
I'm trying to run a plone-ish buildout on Windows for a customer,
currently getting this:
creating zope.proxy
copying zope/proxy\proxy.h - zope.proxy
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible
binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin
installed,
you can try compiling with MingW32, by passing -c mingw32 to setup.py.
While:
Installing zope2.
Do binary eggs exist for zope.proxy and friends?
This isn't a matter of a binary zope.proxy egg. If you look at the
'zope2' part of your buildout.cfg, you'll see it's actually trying to
compile Zope 2 itself (which happens to contain the zope.proxy package
as part of the Zope 3 libraries that it ships with).
What you want to do on Windows is install Zope 2 manually using the
installers, then edit buildout.cfg to NOT build Zope 2, but to refer to
the installation location, e.g.:
[zope2]
location = C:\Path\to\my\zope2
# nothing else here, also remove 'zope2' from buildout:parts
[instance]
...
# stays the same:
zope2-location = ${zope2:location}
...
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: View component registration
David Glick wrote: On Jun 18, 2008, at 1:44 PM, Malthe Borch wrote: Martijn Faassen wrote: There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B? It deserves consideration, but I don't think code will be prone to break since we're merely providing more information to lookup a view component, not less. Exactly. The interface passed to getMultiAdapter or queryMultiAdapter is a minimum requirement. Making views provide IView won't stop them from providing Interface, which is the default. Well, true, view *lookup* for Interface will still work if we register views for a more specific interface. But if Zope's browser publication now starts looking up views with the more specific interface and there are still views around that haven't been registered for that but for Interface, we'll run into backward compatibility problems. I suppose the browser publication would have to be smart about it and do a legacy lookup for Interface if it can't find a view for the specific one. Either way, it's not *that* simple... ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: View component registration
Jim Fulton wrote: On Jun 18, 2008, at 4:31 PM, Malthe Borch wrote: Currently views are registered as components providing zope.interface.Interface; this is unfortunate since other kinds of components may use the same specification, namely (context, request). Right. This is a historical accident that I would love to see corrected. It's just never been a high enough priority. ... Note that resources have the same problem. I suggest we then register views as components providing ``zope.component.IView``; browser views should provide ``zope.publisher.interfaces.browser.IBrowserView``. zope.component isn't the right place. What's more, View isn't the right word. I think this needs more thought, but I think that: - the interface is about publication (not components or views) - the interface is for objects that want to be published, regardless of whether they are adapters. Basically, when you get to the end of URL traversal, you should get an object that wants to be called to get a result and that implements or can be adapted to this interface. Right. I think zope.publisher.interface.browser.IBrowserPage already fits this description, but feel free to correct me if I'm wrong. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: View component registration
Malthe Borch wrote: Currently views are registered as components providing zope.interface.Interface; this is unfortunate since other kinds of components may use the same specification, namely (context, request). An example of this is ``IAbsoluteURL``; it clashes with the resources view*. In the words of Christian Theune: I think it looks like one should never ask for adaptions to Interface. I suggest we then register views as components providing ``zope.component.IView``; browser views should provide ``zope.publisher.interfaces.browser.IBrowserView``. IBrowserView is IMHO not the right one. Anything, including absolute_url and standard_macros, can be a browser view. But browser views aren't necessarily *publishable*. In other words, Zope 3 won't resolve URLs like http://localhost:8080/standard_macros or http://localhost:8080/absolute_url. (Zope 2 will publish such URLs which is quite terrible). Browser pages (as opposed to browser views) are components that *are* publishable on the other hand. That's because they provide IBrowserPublisher (IBrowserPage extends this interface). That's why I think IBrowserPage is the right interface to adapt to. But perhaps it should be something else, though either way it should be based on IBrowserPublisher. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: git mirror of svn://svn.zope.org/repos/main ?
Jeff Kowalczyk wrote: I was going to ask this question anyway, but perhaps it's more timely with the scheduled server move: Has anyone made a git clone of svn://svn.zope.org/repos/main suitable for public mirroring on github, etc.? Not that I know of, but there's a read-only SVN mirror: http://svn.zope.de ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope] Re: Python instance growing while ZTC
Marco Bizzarri wrote: Hi all. Apologies in advance if my question has a somewhat obvious answer. I'm working on a Zope application, developed as a python product. I've ZTC in place for this application. While I run all the ZTC, I can see python process size growing. Can I use this as an indication of a leak of resources in my application? Probably not. I suggest running your tests multiple times in a loop using the -N switch of the test runner. If the memory consumption grows with each repetition of the tests, you may have a leak. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: buildbot failure in Zope on zope.pagetemplate
These failures are due to recent changes to zope.tal (3.5.0) in which the TAL interpreter no longer emits a trailing newline character (and thus finally complies with its own spec). I've fixed this on the zope.pagetemplate trunk now. [EMAIL PROTECTED] wrote: The Buildbot has detected a new failure of zope.pagetemplate on Zope. Full details are available at: http://zopebuildbot.whq.gocept.com/zope.pagetemplate/builds/92 Buildbot URL: http://zopebuildbot.whq.gocept.com/ Buildslave for this Build: local Build Reason: The Nightly scheduler named 'zope.pagetemplate nightly' triggered this build Build Source Stamp: [branch zope.pagetemplate/trunk] HEAD Blamelist: BUILD FAILED: failed test Logs are attached. sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildbot failure in Zope on zope.app.twisted
zope.app.twisted was missing a test dependency (zope.testbrowser) for a level 2 test. Fixed now. [EMAIL PROTECTED] wrote: The Buildbot has detected a new failure of zope.app.twisted on Zope. Full details are available at: http://zopebuildbot.whq.gocept.com/zope.app.twisted/builds/97 Buildbot URL: http://zopebuildbot.whq.gocept.com/ Buildslave for this Build: local Build Reason: The Nightly scheduler named 'zope.app.twisted nightly' triggered this build Build Source Stamp: [branch zope.app.twisted/trunk] HEAD Blamelist: BUILD FAILED: failed test Logs are attached. sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildbot failure in Zope on zope.app.zptpage
Here, the same thing as with zope.pagetemplate happened. zope.tal no longer emits a trailing newline character. Fixed on the trunk. [EMAIL PROTECTED] wrote: The Buildbot has detected a new failure of zope.app.zptpage on Zope. Full details are available at: http://zopebuildbot.whq.gocept.com/zope.app.zptpage/builds/95 Buildbot URL: http://zopebuildbot.whq.gocept.com/ Buildslave for this Build: local Build Reason: The Nightly scheduler named 'zope.app.zptpage nightly' triggered this build Build Source Stamp: [branch zope.app.zptpage/trunk] HEAD Blamelist: BUILD FAILED: failed test Logs are attached. sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Deciphering Zope Comments
Shane Hathaway wrote: Hi all, I'm trying to get a handle on Zope 3. I plan to take a bunch of Zope 3 modules and combine them in a new way. The goal is to create for myself a comfortable working environment that lets me run simple code in a small mod_wsgi environment with easy reloading and no ZODB initially. To achieve this, I need to understand what's going on in the Zope 3 code base. While the code itself is easy to understand, there are many comments in the code that suggest changes are coming soon. Please help me figure out what is meant by these comments. The first cryptic comment comes from zope.component. The _api module starts with this gem: # SiteManager API. This needs to get deprecated eventually. I think this meant to say that the word Site Manager has been deprecated. Nowadays we just say component registry. In theory. I think we just found that renaming things isn't worth all the trouble. But... um... everything in the module uses getSiteManager(). The whole component foundation is built on it. When is it going to be replaced? With what? By whom? I think the comment can go. It's the opposite of useful right now. I'm assuming for the moment that the comment is a lie, and that getSiteManager() is not going away, since otherwise I have no foundation to build upon. Yup. I think I want to use a threading.local as my site manager. That way, I can use a different configuration for each WSGI app even if several apps run in different threads of a single Python interpreter. It looks like the zope.app.component.hooks module does something like what I want, but that module is complicated and lacks comments in the places that matter, so I'm not quite sure what it accomplishes. I'll add comments to that module if anyone can explain it fully. zope.component.getSiteManager() is a hooked function (using zope.hookable). That means it can be replaced by some other implementation. zope.app.component.hooks makes use of that. It replaces zope.component.getSiteManager() with an implementation that looks up a thread local variable (SiteInfo). This replacement is done in the setHooks() function which is called some time during Zope startup. That led me to the zope.thread module, which is apparently deprecated already, yet zope.app.component still depends on it. Is that an hysterical accident? As said previously, zope.thread.local is just a wrapper around Python's threading.local module (which was contributed by Jim based on zope.thread.local). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Buildout parameter parsing
Malthe Borch wrote: I think a valuable extension to the parameter parsing in buildout's configuration language would be to allow += and -= operators, which would append and remove items, respectively. Example: [instance] eggs += Products.PDBDebugMode Singular or plural arguments would be supported. \malthe This isn't the buildout list :). I think buildout matters are discussed on the distutils SIG mailinglist. There's also an issue tracker at https://edge.launchpad.net/zc.buildout. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Re: PageTemplates len() of unsized object
On 2 Jun 2008, at 20:44 , Dieter Maurer wrote: Philipp von Weitershausen wrote at 2008-5-28 21:52 +0200: Dieter Maurer wrote: 2008-05-24T09:31:32 ERROR Zope.SiteErrorLog http://myurl/error_log/manage_main Traceback (innermost last): Module ZPublisher.Publish, line 119, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 42, in call_object Module Shared.DC.Scripts.Bindings, line 313, in __call__ Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec Module Products.PageTemplates.PageTemplateFile, line 129, in _exec Module Products.PageTemplates.PageTemplate, line 89, in pt_render Module zope.pagetemplate.pagetemplate, line 117, in pt_render Module zope.tal.talinterpreter, line 271, in __call__ Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 379, in do_startEndTag Module zope.tal.talinterpreter, line 412, in do_startTag TypeError: len() of unsized object ... As far as I can tell, the code in zope.pagetemplate and zope.tales still has the same traceback information that Products.PageTemplate had. zope.tal, which contains the TAL interpreter, doesn't have any traceback supplements, but then again, Zope 2's TAL package doesn't either. To conclude, I don't think there's a step backward at all. The Zope 2.9 code had traceback support in PageTemplate.pt_render which told us which template was affected. As you can see in the traceback above, at least this traceback support is lost in Zope 2.10. To conclude: no step backward at all is incorrect. Looking at Zope 2.11, the traceback support above seems to have been resurrected. Furthermore, I could not find the equivalent of the transback support which formerly was in Expressions.py (I found the one corresponding to TALES and PythonExpr). Thank you for that careful analysis. I was only comparing Zope 2.9 with Zope 3 (which are AFAICT equivalent in their traceback info) but I didn't take 2.10 into consideration. I've now filed a bug report at https://bugs.launchpad.net/zope2/+bug/236938 to make sure the issue isn't lost. I will look into it a.s.a.p. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: PageTemplates len() of unsized object
Dieter Maurer wrote: Giampiero Benvenuti wrote at 2008-5-24 11:47 +0200: ... after the upgrade from zope2.9.7 to 2.10.6 i get this error in the event log: 2008-05-24T09:31:32 ERROR Zope.SiteErrorLog http://myurl/error_log/manage_main Traceback (innermost last): Module ZPublisher.Publish, line 119, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 42, in call_object Module Shared.DC.Scripts.Bindings, line 313, in __call__ Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec Module Products.PageTemplates.PageTemplateFile, line 129, in _exec Module Products.PageTemplates.PageTemplate, line 89, in pt_render Module zope.pagetemplate.pagetemplate, line 117, in pt_render Module zope.tal.talinterpreter, line 271, in __call__ Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 379, in do_startEndTag Module zope.tal.talinterpreter, line 412, in do_startTag TypeError: len() of unsized object Looks as if the Zope 2.10 PageTemplate implementation made a big step backward with respect to quality of traceback information :-(( As far as I can see, traceback information was never added within the TAL interpreter but always for TALES expression evalutation. The traceback above seems to be about something going wrong within the TAL interpreter which is probably why we don't see any further traceback info. Shane had added lots of __traceback_info__ and __traceback_supplement__ declarations to the older code such that the tracebacks were very informative ... unlike the traceback above. As far as I can tell, the code in zope.pagetemplate and zope.tales still has the same traceback information that Products.PageTemplate had. zope.tal, which contains the TAL interpreter, doesn't have any traceback supplements, but then again, Zope 2's TAL package doesn't either. To conclude, I don't think there's a step backward at all. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: dtml-tree documentation
Andreas Jung wrote: Is there a complete documentation of the dtml-tree tag anywhere? The dtml reference of the Zope book has the following for some options: This attribute is for advanced usage only Where can I find out about this 'advanced usage'? Using DTML and related DTML tags is like driving a SUV in the time of climate change. Better look a ZopeTree or something similar (I think there was something like SimpleTree - Google). zope.app.tree has a bunch of adapters and helpers for creating complex folding trees with any sort of templating mechanism, including Page Templates. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: Five registerPackage results in unresolved ConflictError
Believe something very very rotten in Five's registerPackage was fixed by Rocky in r72986 [1]. As far as I can tell this was never merged to the 1.4 branch, but I could we wrong. [1] http://svn.zope.org/?rev=72986view=rev Sasha Vincic wrote: Forgot to say that this is Zope 2.9.8, Five 1.4 branch from svn, Plone 2.5.5 /Sasha On Fri, May 16, 2008 at 12:03 PM, Sasha Vincic [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi On a server we have a ZEO server with 6 clients. When we start/restart the server we often get on random instance an AttributeError @@plone and all other browser pages. I have tracked it down to a ConflictError when installing Five on startup. See traceback bellow. To solve this I tried to set enable-product-installation = off to all except one instance but I still got errors. For now we restart the broken instances until they work, I have tried to set sleeping times up to couple seconds between the instances but it didn't make any difference. Five fails when it tries to execute the registerPackage in zcml files. Not the same product every time. First I thought it didn't respect the enable-product-instalation but that is checked in App.Product.initializeProduct method. So I played in fiveconfigure.py with transaction.savepoint() but no success but if I manually check App.Product.doInstall like in the diff below Now my question is if this is correct solution for the problem or will it have other side effects that I am not aware of? How do I write tests for an ConflicError during startup? /Sasha Index: fiveconfigure.py === --- fiveconfigure.py(revision 86781) +++ fiveconfigure.py(working copy) @@ -23,7 +23,7 @@ import warnings import App.config -from App.Product import initializeProduct +from App.Product import initializeProduct, doInstall from App.ProductContext import ProductContext import Products from zLOG import LOG, ERROR @@ -265,6 +265,8 @@ if not hasattr(module_, '__path__'): raise ValueError(Must be a package and the \
[Zope-dev] Re: zope.testing console script
Tarek Ziadé wrote: If nothing exists, I would like to suggest adding a setuptools console entry point in zope.testing setup.py file, to get a python script in the $PYTHON/bin folder, exactly like what zc.recipe.testrunner does. +1 It could be called zope.testrunner maybe ? (nose= nostests, py.test = py.test) I suppose having it called 'test' (which is our convention) is a bit arrogant. But calling it 'zope.testrunner' creates the allusion that the package is called zope.testrunner as well. How about 'run-zope.testing' or something along those lines? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: NotFound
Roger Ineichen wrote: Is there a reason why zope.publisher.interfaces.NotFound is not locatable? class NotFound(LookupError, TraversalException): implements(INotFound) def __init__(self, ob, name, request=None): self.ob = ob self.name = name Why should a NotFound error instance not be locatable by default since it provides a location? What kind of a location does it provide? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: i18nmessageid has a broken link
Sebastian Wehrmann wrote: the zope.i18nmessageid package has a broken link on http://download.zope.org/zope3.4/zope.i18nmessageid/ . The 'zope.i18nmessageid-3.4.3-py2.4-linux-i686.egg' does not exist any more on pypi. Right. It was deliberately removed because binary eggs should never ever be uploaded (unless they're for Windows). Could someone please fix it? I'm cc'ing Stephan Richter who maintains the KGS. I think this is a matter of re-generating the KGS index that sits at http://download.zope.org/zope3.4. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: i18nmessageid has a broken link
Maurits van Rees wrote: Without having tried pure Zope 3, only Grok --- I have been working on grokproject during the Grokkerdam sprint --- the following in buildout.cfg should work just as well: find-links = http://download.zope.org/distribution/ extends = http://download.zope.org/zope3.4/versions.cfg versions = versions The find-links is needed because it has some package versions that were never released on the cheese shop. The versions.cfg defines which versions are actually used. What packages are not released on PyPI yet? I was under the impression that find-links is no longer needed. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Why I dislike narrative doctests
Lennart Regebro wrote: On Thu, Apr 24, 2008 at 10:07 PM, Jim Fulton [EMAIL PROTECTED] wrote: - If a file is documentation and a test, make sure it is good documentation. In that case, documentation comes first. Don't add so many tests that it ruins the documentation. - Test edge cases in separate tests. These are typically short-ish strings in test modules. - A variation is to have a narrative that doesn't try hard to be documentation. The narrative can be convenient, up to a point, even in a test. These should be clearly marked as not being documentation. I'ö happy to here this from an authorative source. I've been saying it for years, and I have usually been contradicted by people saying no all tests should be doctests, Lets kill that sillyness once and for all now. :-) I've written such rules down: http://svn.zope.org/Sandbox/philikon/foundation. If it's missing something, feel free to suggest a patch. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope.org Redux] Re: [Zope-dev] Let's fix the damned website
On 21 Apr 2008, at 11:53 , Martin Aspeli wrote: - Projects gives an explanation of how the different Zope projects fit together (Zope 2, Zope 3, Grok, CMF, ZODB). Each is then given a subfolder that contains a standard structure: A front page that explains the project in more detail, Get (downloads), Taste (as above, but for a particular project) and Learn. The Learn section should contain relevant, up-to-date documentation. No! Each project should have it's own site. Like Grok has today. The Projects page which explains what they are and how they fit together is fine, but the different subparts will necessarily have to be maintained by slightly different people with slightly different requirements. We can set up rules so that both zope.org/Projects/grok and grok.zope.org point to the same physical place, but it is extremely important that we do not, once again, try to make a monolithic zope.org. Microsites, microsites, microsites! Does it really matter whether a microsite lives in zope.org/projects/zodb or zodb.zope.org? If you look at the projects now, they each have a common set of sections - download, examples, documentation - and will be allowed to evolve independently. They also have the option of having some specific branding (logo, tag-line etc) as required. If anyone steps up and wants to maintain a separate site for one of the projects, then all the better. However, it is hard enough to get contributors as-is, so I'm loth to do anything that increases the maintenance or setup burden in any way until we have at least the basics in place. I agree with Martin. We need to stop the balkanization of Zope-the- brand. Yes, we have many individual projects, but we need a coherent image to the outside world. Microsites was a good idea to get foundation site and the Grok site up and running *before* tackling zope.org, but in the long run, we need coherence. Also, to be honest, I don't find the design of the new Grok website very attractive. And the foundation site is simple enough to be folded back into the main site. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
On 19 Apr 2008, at 22:39 , Chris McDonough wrote: Philipp von Weitershausen wrote: Chris McDonough wrote: I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input. IMO, a Zope2 egg release should depend on the following packages: - 'ZODB3' (already packaged) - 'transaction' (depended on by newer ZODBs) - 'ZConfig' (also depended on by newer ZODBs) - 'StructuredText' (should be broken out into its own egg) - 'docutils' (should use existing egg) - 'mechanize' (should use existing egg) - 'pytz' (should use existing egg) - all zope.* packages (properly pinned) that zope2 depends on Yup. These are all done already. The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc). Yup, we can do it like that. I still maintain that the zLOG, Interface and DateTime packages could be packaged separately without much effort. The benefit with those is that they'll either be obsolete very soon (zLOG, Interface) or may need off-beat updates (DateTime). I'd be slightly happier if everything we (Zope 2 folks, as opposed to Zope 3 folks, ZODB folks, or other independent authors) maintain shipped inside a single egg. In particular, I think this might be what to aim for in the very first Zope 2 egg-based release, because we can always move stuff out in a later release, but it's harder to reel something back in if we find that moving it out has been a mistake. The one big egg strategy might also let us explain it a little more easier to old- hand Zope2 devs who aren't used to eggs: everything that used to be in the tarball except ZODB, Zope 3 libraries, and external libs is in the zope2 egg. Then in a subsequent Zope 2 egg release, we could say oh, now that you're used to eggs, we've moved DateTime out into a separate egg, so on and so forth. Ok, fine by me. But I'll try not to get hung up on it if other really want to bust things apart. I guess in particular, I'm not keen on trying to externalize ExtensionClass or Acquisition unless somebody else has a strong desire to do this because they're using them outside Zope somehow. Which they're not :). We might call it 'zope2libs'. What's wrong with just 'Zope2'? It would be nice to disambiguate the libraries needed to run Zope 2 from the wrapper stuff required to configure an instance. The very outmost meta-egg (or buildout, or whatever) should probably be named Zope2. This might or might not be it. If this *is* that outermost egg, Zope2 sounds good to me. Well, taking your everything that used to be in the tarball... argument, then this would indeed be the outmost egg, incl. the instance scripts. A nit: I might call the outermost egg zope2 because I have a preference for lowercase egg names and we also already have a *package* named Zope2, and it'd be nice to know where you are at the bash prompt without needing to print the whole path. I have a slight preference for Zope2 because that's what egg names usually look like. Also, if you told people Zope 2 was now available in egg form and asked them to guess what the egg was called, I think most would come up with Zope2. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
Chris McDonough wrote: I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input. IMO, a Zope2 egg release should depend on the following packages: - 'ZODB3' (already packaged) - 'transaction' (depended on by newer ZODBs) - 'ZConfig' (also depended on by newer ZODBs) - 'StructuredText' (should be broken out into its own egg) - 'docutils' (should use existing egg) - 'mechanize' (should use existing egg) - 'pytz' (should use existing egg) - all zope.* packages (properly pinned) that zope2 depends on Yup. These are all done already. The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc). Yup, we can do it like that. I still maintain that the zLOG, Interface and DateTime packages could be packaged separately without much effort. The benefit with those is that they'll either be obsolete very soon (zLOG, Interface) or may need off-beat updates (DateTime). We might call it 'zope2libs'. What's wrong with just 'Zope2'? What needs to get worked out is the ability to share headers between ZODB and this package so things can compile properly. I don't see this as a huge problem. You have a point that C headers introduce un-documented dependencies, but then again, how often do C headers change? It has worked so far with externals to the ZODB tree, it's not like anything's going to change there any time soon. (For instance, when I hacked Acquisition to support __parent__ pointers, I didn't have to change the headers either). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Merge philikon-aq branch into Zope trunk
Martijn Faassen wrote:
Tres Seaver wrote:
[snip]
The second problem that might arise, is that the implicit assumption
that every object inside Zope 2 inherits from Acquisition base
classes no longer holds. Code that relies on the various aq_*
attributes to be there need to be adjusted to use the Acquisition
methods instead.
The major downside here is that restricted code doesn't have access to
the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and
hence use the attributes. ('aq_base' should not be allowewd at all, as
it strips away security context).
There are probably thousands (or even tens of thousands) of templates
and scripts in the wild which use these attributes. I don't think we
can break them in a single release: we need to deprecate them first
(with suitalbe logging output), and maybe even provide
'__parent__'-aware workarounds / fallbacks in their implementations.
I'm trying to understand what is proposed that would break them. All
existing content objects will continue to use acquisition. Only things
like Five views will stop using acquisition and switch to a __parent__
pointer. I doubt there are that many scripts that rely on getting a
.aq_parent, say, on a Five view. There will be view code that relies on
this, so I imagine we expect that should be rewritten to use the
functions instead, but not scripts.
You're right, and Tres acknowledged that in a follow-up post already :).
What's more, views actually *do* have those aq_* attributes for BBB, so
even those scripts that do view.aq_parent will continue to work no
problem. See my answer to Tres's post.
If we were to change OFS so that it'd start using __parent__ then I can
see where you're coming from, but I don't think anyone's proposing that?
Nope. And it would be quite an involved thing to do, because currently
Zope 2 objects have no persistent reference to their parent whatsoever
(in fact, parent i.e. cyclic references used to be unsupported by early
ZODB versions). So basically, if you wanted to introduce __parent__
pointers to existing Zope 2 objects, you'd have to traverse the whole
object tree and set them based on their acquisition parent. I *suppose*
this could be done ad-hoc (when you first traverse over an object that
doesn't yet have its __parent__ pointer set), but I'd rather not think
this through right now.
So, like I said, it's not on my list, and I bet it won't be for a long
time. Mostly because a) it's probably unnecessary and b) much code in
fact relies on content being of the type Acquisition.Implicit...
dtml-var standard_dtml_header anyone? :)
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/philikon-aq/lib/python/Products/Five/browser/pagetemplatefile.py Remember that Hanno's fix should probably be made in zope.app.pagetemplate.
Log message for revision 85467: Remember that Hanno's fix should probably be made in zope.app.pagetemplate. Changed: U Zope/branches/philikon-aq/lib/python/Products/Five/browser/pagetemplatefile.py -=- Modified: Zope/branches/philikon-aq/lib/python/Products/Five/browser/pagetemplatefile.py === --- Zope/branches/philikon-aq/lib/python/Products/Five/browser/pagetemplatefile.py 2008-04-18 07:50:23 UTC (rev 85466) +++ Zope/branches/philikon-aq/lib/python/Products/Five/browser/pagetemplatefile.py 2008-04-18 12:43:22 UTC (rev 85467) @@ -38,6 +38,10 @@ id = property(getId) +# TODO: This is basically a copy'n'paste job from the base class, +# just to rename the 'instance' keyword argument and thus to allow +# this argument to occur in **keywords. Ideally, we should put this +# fix in zope.app.pagetemplate and get rid of the duplication here. def __call__(self, __instance, *args, **keywords): instance = __instance namespace = self.pt_getContext( ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy Improve doctest paragraph about calling templates that are instance variables.
Log message for revision 85468:
Improve doctest paragraph about calling templates that are instance variables.
Changed:
U
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy.py
U
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy.zcml
U
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy_ftest.txt
-=-
Modified:
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy.py
===
---
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy.py
2008-04-18 12:43:22 UTC (rev 85467)
+++
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy.py
2008-04-18 12:53:20 UTC (rev 85468)
@@ -49,12 +49,13 @@
def __call__(self):
return self.template()
-class LegacyTemplateTwo(BrowserView):
+class InstanceTemplate(BrowserView):
def __init__(self, context, request):
self.__parent__ = context
self.context = context
self.request = request
+# This is wrong (even though it used to work before):
self.template = ViewPageTemplateFile('falcon.pt')
def __call__(self):
Modified:
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy.zcml
===
---
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy.zcml
2008-04-18 12:43:22 UTC (rev 85467)
+++
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy.zcml
2008-04-18 12:53:20 UTC (rev 85468)
@@ -24,8 +24,8 @@
browser:page
for=*
- name=template_two
- class=.aqlegacy.LegacyTemplateTwo
+ name=instance_template
+ class=.aqlegacy.InstanceTemplate
permission=zope.Public
/
Modified:
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy_ftest.txt
===
---
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy_ftest.txt
2008-04-18 12:43:22 UTC (rev 85467)
+++
Zope/branches/philikon-aq/lib/python/Products/Five/browser/tests/aqlegacy_ftest.txt
2008-04-18 12:53:20 UTC (rev 85468)
@@ -166,37 +166,35 @@
Testing keyword arguments
=
-ViewPageTemplateFile's take arbitrary keyword arguments:
+Instances of ViewPageTemplateFile can be accessed from outside the
+view and called. They take arbitrary keyword arguments:
view = getMultiAdapter((self.folder, request), name='template')
template = view.template
print template(foo=1, bar=2)
pThe falcon has taken flight/p
-Passing in an argument called instance was supported by the old Five version
-of ViewPageTemplateFile, so we still need to support it.
+Passing in an argument called ``instance`` was supported by the old
+Five version of ViewPageTemplateFile, so we still need to support it:
-In the zope.app.pagetemplate version, the first required argument is called
-instance, though.
-
print template(instance='allowed')
pThe falcon has taken flight/p
-No arguments required
-=
+Class-level templates only
+==
-ViewPageTemplateFile's require no arguments, but you can only use them as
-class variables:
+ViewPageTemplateFile instances can only be used as class attributes.
+If you put one on an instance (as does the following view), you'll get
+a ``TypeError`` when you try to render the template:
- view = getMultiAdapter((self.folder, request), name='template_two')
+ view = getMultiAdapter((self.folder, request), name='instance_template')
print view()
Traceback (most recent call last):
...
TypeError: __call__() takes at least 2 arguments (1 given)
-
Clean up
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-dev] Re: Proposal: Merge philikon-aq branch into Zope trunk
Tres Seaver wrote:
The second problem that might arise, is that the implicit assumption
that every object inside Zope 2 inherits from Acquisition base classes
no longer holds. Code that relies on the various aq_* attributes to be
there need to be adjusted to use the Acquisition methods instead.
The major downside here is that restricted code doesn't have access to
the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and
hence use the attributes. ('aq_base' should not be allowewd at all, as
it strips away security context).
There are probably thousands (or even tens of thousands) of templates
and scripts in the wild which use these attributes. I don't think we
can break them in a single release: we need to deprecate them first
(with suitalbe logging output), and maybe even provide
'__parent__'-aware workarounds / fallbacks in their implementations.
Here's the deal:
* Instances of (subclasses of) Acquisition.Implicit and .Explicit still
have those aq_* attributes. So basically all content objects still have
them, no change there.
* Five's BrowserView class doesn't inherit from Acquisition.Explicit
anymore, but we've provided the aq_* attributes for backward
compatibility. So if a template does view/aq_parent, it will still work
(we have tests for this). We haven't set an expiry date for this BBB,
nor are we logging a warning. We probably should, though, if we
eventually want to phase out Five's BrowserView class.
So, off the line there's no backward-compatibility problem. Now if
people decide to implement their content objects without Acquisition
(which they now can), then it's their problem if their templates still
do obj/aq_*. This can be alleviated with a mix-in that Five has, which
makes classes regain the aq_* attributes. Not sure if we want to make
this public in any way, currently it's basically used for BrowserView
and ViewletBase.
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Merge philikon-aq branch into Zope trunk
Hanno Schlichting wrote: Timeline: I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems. Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test. This sounds good. Here's another idea, though: In accordance with release early and often, how about scheduling the 2.12 release shortly after the 2.11 one? So the only new thing in 2.12 would be the philikon-aq branch (it would still ship with the same Zope 3 libraries as 2.11, etc.). Opinions, votes? +1 :) P.S. Thanks to philiKON for doing most of the work on this branch :) And thanks to Hanno for testing it against Plone and making lots of improvements! ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AQ-Parent branch test failues was: Re: Five and browser-oriented components
Thanks for looking into this, Hanno! Here's my feedback: Hanno Schlichting wrote: Hanno Schlichting wrote: I kept my promise and added the simple tests for the first two issues I found while doing testing against Plone. I have meanwhile fixed the first trivial issue (conflicting argument called 'instance') I took a look at it. Thanks! It's too bad that we have to duplicate so much code from Zope 3 now. Therefore I would suggest that we fix up zope.app.pagetemplate properly so that it won't conflict with 'instance'. Then we can get rid of the duplication in Five. Thanks to the individual projects nowadays, it should be trivial to update zope.app.pagetemplate. [...] Now as you can see the only difference is that one of them uses a class variable for assigning the template and the other one is using an instance variable. ViewPageTemplateFile etc. are only meant to be used as class attributes, never as instance attributes. This statement is also true for the current, acquisition-based one from Five. In my opinion, the fact that it accidentally worked as an instance variable isn't a very strong argument for continuing to support it. To me, this is a prime example of misusing a Five component which now leads to problems when we go pure Zope3. From what I understand some magic place in between doesn't find the template instance variable during ZCML processing as it operates on classes only and therefor doesn't turn the template into a BoundPageTemplateFile. It doesn't happen during ZCML processing. It's a simple class descriptor, so the magic happens in ViewPageTemplateFile's __get__ which is invoked each time you do view.template (the '.' invokes __get__). I recommend reading about new-style class descriptors and properties. Using an instance variable called template and calling it later on without passing in the view as the first argument doesn't work at all in Zope3. In Zope2 it did so far, as the ViewPageTemplateFile would use Acquisition to find its view. Right. This led to all sorts of weird and icky problems, so thank God it's gone now. I don't have any good idea on how to handle this problem. Do we really have to support instance-level templates? I would still argue that if anybody's using ViewPageTemplateFile like this, they're using it wrong. I personally have no intent on supporting this. If we really have to support it, then there's a simple solution: don't use ViewPageTemplateFile for instance-level attributes, use a variant that we provide instead. We could introduce this variant in both pre-AQ-parent and post-AQ-parent Zope versions to ease compatibility. We can probably walk up the stack frame to find the view in most cases, as the template is called in almost all cases directly from the view. -1. Walking up stack frames for guessing stuff like this will usually destroy you. But the third test failure, which I haven't written a test for yet, breaks even then. Essentially it puts in an adapter in between the view and the template where the adapter doesn't have any reference to the view anymore, so getting to the view from the template is impossible even by walking up the stack frame. This use-case is highly specialized (the code is in plone.app.form._named) but currently it works in Zope2. You're probably referring to the NamedTemplate thing that zope.formlib has (and plone.app.form reimplements the stuff for Zope 2). In zope.formlib, the same __get__ technique that ViewPageTemplateFile uses is used to get a hold of the view instance when you do view.template. plone.app.form's replacement for this technique is to use acquisition to get at the view. This obviously has to go since acquisition is no longer supported for views. In fact, if I'm not mistaken, this bit of plone.app.form can entirely be ripped out. Given that plone.app.form does monkey patches (which I'm unwilling to support in any means, the original authors made potential incompatibilities their problem when they introduced them), I'm almost certain that there will never be one version of plone.app.form that will work with both the pre-AQ-parent and the post-AQ-parent Zope. You could still try, of course. At the very least, you could make a try/except clause. Either way, as I said, I'm not offering my help for this package since it contains monkey patches. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AQ-Parent branch test failues was: Re: Five and browser-oriented components
Wichert Akkerman wrote: Previously Philipp von Weitershausen wrote: ViewPageTemplateFile etc. are only meant to be used as class attributes, never as instance attributes. This statement is also true for the current, acquisition-based one from Five. Is that documented anywhere? I can't seem to find any interface or docstring that documents that. I suppose not, because ViewPageTemplateFile (or ZopeTwoPageTemplateFile, as it used to be called) was and still is poorly documented. Initially, it was only used internally by the ZCML directives until people started writing the view template explicitly into the view class, much like in Zope 3. So no, there isn't documentation about the Five bit. But there *is* documentation about the Zope 3 bit (my book, for instance), so my argument is mostly based on the principle of correspondence between Five and Zope 3. In my opinion, the fact that it accidentally worked as an instance variable isn't a very strong argument for continuing to support it. To me, this is a prime example of misusing a Five component which now leads to problems when we go pure Zope3. I'ld agree if there was a docstring or interface that made that explicit. I've updated the relevant code in plone.app.portlets though since the change is harmless. Cool, that's great. If this is just a matter of a docstring, I'm sure that can be arranged :) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Malthe Borch wrote: On Z2, certain imports need to come from Products.Five, to play nicely with ZPublisher and friends. Not really. You can inherit from zope.publisher.browser.BrowserView and Five's browser:page / directive will magically slap Acquisition.Explicit into a newly-created subclass that will be registered as a view. I'd like to ask for the motivation for not patching it onto the existing classes and/or modules. Because monkey-patches are evil. And I won't accept any buts here. They're just evil, hard-to-impossible to test and most important of all, absolutely unfathomable for the novice developer. The effect of having Z2-developers import from Products.Five is that they must opt out on packages that make use of templates, browser views, formlib, ... --- and it adds needless complexity. AFAIK, Plone already monkey patches formlib so you won't even have to change those imports. This split might also have prompted the Plone community to walk their own way to the extend that there isn't much code reuse outside of the core Zope packages (along with egg dependencies, but with our fake eggs, we're almost up to par here). I still believe the answer is my Acquisition + __parent__ patch. As mentionen in this thread already, it's several years old now (yikes!) but should merge quite cleanly, actually. Zope's own tests pass nicely, as do the CMF's, only Plone's tests fail in one or two places in an obscure way (and I'm talking about the whole ploneout testsuite here). *IF* you'd like to be pragmatic, I'd suggest we clean up those failing Plone tests, merge the branch and be on our way. Yes, we *might* be plastering over a potential problem in the patch, but the other tests didn't seem to be affected and intensive alpha and beta testing of that new Zope version would likely confirm or refute the existence of a serious problem. To be honest, my suspicion is that Plone is using some of the Five stuff in a way that it shouldn't be, hence causing a test failure with the cleaned up Five. Hanno removed some of the Five-raping procedures in Plone already, but there might be others lurking around and causing test failures. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Martijn Faassen wrote: Technically, I think that this is going to be hard. You'd need to patch in the magic acquisition base class. Acquisition is the main reason that some of the code needed to be duplicated - without the existence of acquisition wrappers, security checks are not made for view access and things just won't work. I think if we could finish the philikon-aq_parent branch (or whatever it's called) that makes it possible to do acquisition using __parent__ pointers, we'd be a lot closer. AFAIU, that branch doesn't provide *acquisition* via the __parent__ pointer: No, it does. It makes __parent__ pointers completely equivalent to explicit acquisition wrappers. rather it allows the containment-based security check, which currently uses the 'inner' acquisition wrapper, to use the chain of '__parent__' pointers as an alternative when no acquisition wrapper is present. The security machinery (AccessControl) does an aq_aquire(obj, '__roles__') check. With __parent__ pointers, this will resolve properly. The branch is indeed ready from Zope's own point of view. Last thing I remember is that one (!) Plone tests fails in an obscure way. Then again, one failing test sometimes is enough :) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?
Wichert Akkerman wrote: Previously Martin Aspeli wrote: I'm not sure this is all that useful. For Plone 4, we're just going to have a number of plone.*, plone.app.* and Products.* (and a few others, like kss.*) eggs that we can put in a KGS or version pin in a single Plone egg. For Plone 4 we may also collapse all the plone.app.* packages in a single package. +sys.maxint ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?
Philipp von Weitershausen wrote: Andreas Jung wrote: during the latest 'zope.publisher' thread on zope-dev I came up with the proposal to eggify the Zope core for the Zope 2.12 release. I would like to start a discussion about the pros and cons, risks and advantages of any eggification effort. Chris favors a 'big' Zope egg with some dependencies (like ZODB) stripped out. I have pretty much done this already. [1] defines an egg called 'Zope2'. All the Zope 3 eggs are dependencies, as are a few non-core packages such as ExtensionClass, Acquisition, etc. (which are already eggified and available on PyPI). I should add here that the 'Zope2' egg is far from finished. The things I split off (Acquisition, DateTime, ExtensionClass, etc.) are working fine by themselves, but the 'Zope2' egg needs some more attention to get its tests passing and to get it working in a production environment. I think *one* good goal of this sprint could be to switch repoze.zope2 over from using the 'zopelibs' egg to using the 'Zope2' egg. The 'Zope2' egg should still work by itself in an instance-like fashion, obviously. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?
Andreas Jung wrote: during the latest 'zope.publisher' thread on zope-dev I came up with the proposal to eggify the Zope core for the Zope 2.12 release. I would like to start a discussion about the pros and cons, risks and advantages of any eggification effort. Chris favors a 'big' Zope egg with some dependencies (like ZODB) stripped out. I have pretty much done this already. [1] defines an egg called 'Zope2'. All the Zope 3 eggs are dependencies, as are a few non-core packages such as ExtensionClass, Acquisition, etc. (which are already eggified and available on PyPI). I also started a branch of the Plone egg back then to see if it can be modified to install Zope 2 completely as a dependency. See [2]. I would prefer a more broader approach. One of the reasons are company-internals modifications to the Zope core. Right now we maintain a more or less heavy modified version of Zope 2.8 in our repos (making Zope upgrades pretty hard). A better modularization would help us here. Another example: the Plone people maintained a Zope 2.10 branch with experimental ZODB blob support. With an eggified version of ZODB you could easily switch the eggs (easily spoken). I feel indifferent to this in general, so feel free to split away more stuff from my 'Zope2' egg. So before promoting the eggification as an ultimate goal, let's discuss what we really need and want. A complete eggification just for the sake of eggs is possibly not the goal :-) [1] http://svn.zope.org/Zope2.buildout [2] http://svn.plone.org/svn/plone/dist/Plone/branches/philikon-buildoutify ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] more on stacked component registries
On 5 Feb 2008, at 19:23 , Chris Withers wrote: Stephan Richter wrote: On Tuesday 15 January 2008, Chris Withers wrote: For what I'm after, I need to have a more dynamic buildup of registrations based on which objects have been traversed through. Right. I think the component architecture is not really made for this. Sure it is, I'm talking about what basically happens with nested site managers. The problem is that the current nesting implementation seems predicated on zodb-like persistence. I'm looking at storing all data, including site managers, in a relational database. The actual folder structure should remain as static as it does with zodb... Well, each place in the ZODB will still know that it is a site, i.e. that it has a site manager associated, right? Because then you can easily track down the same registry over and over again. You could probably even register them as global utilities for easy access (like it's done with other registries, e.g. the ones from z3c.baseregistry). I think it would be easier to turn on/off registrations by using dynamically directly provided interfaces (via a proxy) or use security. Not sure what you mean by either of these... You can change which adapters are found for a particular object by applying marker interfaces. - stack the registries up during travesal in some way. I guess this would be a variant of what's done now with current nested registries. Is this feasible? Will there be performance problems? I think the performance would decrease, because caches cannot be built up. Also, you then must be able to access this custom registry. Remember, this must be all in memory, because of thread- safety! Yeah, but this is what happens more static-ly with the existing site managers, right? I'm not sure how the ZODB-based registries do caching. I strongly suspect that their caches may be garbage-collected at any time after the request is over. Also, let's not worry about premature optimizations right now... - use one global registry and add/remove registrations during traversal as necessary. How fast is registration/unregistration of adapters and the like? How many adapter adds/removes at a traversal node would it take to really slow things down? You cannot do this; it is not thread-safe. Well okay, one registry per thread... would that work? So you would basically copy the whole global registry to a thread- local variable at the beginning of the request, then modify it and then throw it away afterwards? Doesn't sound very clever to me... ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope] Re: Upgrade Five for Zope 2.9.7?
James Robertson wrote: How do I upgrade Five (http://codespeak.net/z3/five/) from v1.3.8 to v1.4.4 in Zope v2.9.7? The Plone product I wish to install (Reflecto v1.2 - http://plone.org/products/reflecto) apparentl. requires v1.4.1+. Frustratingly, the installation page (http://codespeak.net/z3/five/INSTALL.html) and INSTALL.txt file for Five do not actually explain how to install it. Just drop the 'Five' directory into your instance's 'Products' directory, just like you would install any other product (e.g. Reflecto). Plone, btw, should already ship with Five 1.4.x. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
