Re: [Zope-dev] make zope.component.registry.Components inherit from dict?
Chris McDonough wrote: Chris McDonough wrote: Off the top of my head, another way to think of this *might* be to say that the 'dict access' is basically looking up a *named* utility providing a very generic marker interface, e.g. zope.component.interfaces.IUtility or even just zope.interface.Interface. That way reg['foo'] == getUtility(IUtility, name='foo'). Obviously, assignment would register in the same way. I'm not sure it's better, though. :) That would also be fine, and it would normalize things a bit, although the implementation would be harder and it would result in slower lookups. But if it made folks feel better than inheriting from dict, I'd be +1 on it. Meh, I just remembered that I tried this. The current implementation requires that the name value be a literal string object (or at least something convertable to Unicode). I think we could relax this requirement; it really only needs to be hashable. I wouldn't want to deploy the API if the keys were required to only be strings. Should be easy to fix, I'm sure. Why would you want something other than strings, though? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] make zope.component.registry.Components inherit from dict?
Chris McDonough wrote:
OK after rereading this, I think we may be massively overthinking this. The
above is getting kinda silly. I can't think of a use case where being able
to
alternate between:
reg.utils['root_factory']
and
reg.getUtility(IAnonymousUtility, name='root_factory')
... is at all useful. I may be wrong. Can you think of one?
If not, it's a lot easier to document:
The utils attribute of a registry is a dictionary that may contain arbitrary
key/value pairs.
Than it is to document:
The utils attribute of a registry is a DictInterface which exposes the
Python
dictionary API which does unnamed utility registrations using the
IAnonymousUtility interface as the utility interface and the key value passed
to the various API methods as the utility name.. and so on
Could maybe we instead just do:
class Components(object):
def __init__(self, name='', bases=()):
self.utils = {}
This would be faster, simpler to document, and would require exactly one line
of code.
Except at this point we've lost all the other ZCA stuff. You can't
override with a local utility, for example. In fact, this is not a ZCA
utility at all, it's just a key-value pair in a threadlocal. It
doesn't have any consistency with named utilities or adapters or any
other aspect of the ZCA.
I'm not saying having just a thread-local dictionary is a bad idea,
but maybe it's not a ZCA responsibility at all. Why would you really
expect it on getSiteManager().utils or whatever? Maybe it's better to
look into the stacked variables that Pylons uses for some of its
configuration stuff?
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/2.12/ Added IPubBeforeAbort event to mirror IPubBeforeCommit in failure scenarios.
Log message for revision 105589:
Added IPubBeforeAbort event to mirror IPubBeforeCommit in failure scenarios.
This event is fired just before IPubFailure, but, crucially, while the
transaction is still open.
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U Zope/branches/2.12/src/ZPublisher/Publish.py
U Zope/branches/2.12/src/ZPublisher/interfaces.py
U Zope/branches/2.12/src/ZPublisher/pubevents.py
U Zope/branches/2.12/src/ZPublisher/tests/testpubevents.py
-=-
Modified: Zope/branches/2.12/doc/CHANGES.rst
===
--- Zope/branches/2.12/doc/CHANGES.rst 2009-11-12 21:21:32 UTC (rev 105588)
+++ Zope/branches/2.12/doc/CHANGES.rst 2009-11-13 05:59:41 UTC (rev 105589)
@@ -11,6 +11,10 @@
Features Added
++
+- Added IPubBeforeAbort event to mirror IPubBeforeCommit in failure scenarios.
+ This event is fired just before IPubFailure, but, crucially, while the
+ transaction is still open.
+
- Include bytes limited cache size in the cache parameters ZMI screen.
- Officially supporting Python 2.6 only (with inofficial support for
Modified: Zope/branches/2.12/src/ZPublisher/Publish.py
===
--- Zope/branches/2.12/src/ZPublisher/Publish.py2009-11-12 21:21:32 UTC
(rev 105588)
+++ Zope/branches/2.12/src/ZPublisher/Publish.py2009-11-13 05:59:41 UTC
(rev 105589)
@@ -27,7 +27,7 @@
from zope.event import notify
from pubevents import PubStart, PubSuccess, PubFailure, \
- PubBeforeCommit, PubAfterTraversal
+ PubBeforeCommit, PubAfterTraversal, PubBeforeAbort
class Retry(Exception):
Raise this to retry a request
@@ -173,8 +173,12 @@
)
retry = True
finally:
+
# Note: 'abort's can fail. Nevertheless, we want end request
handling
try:
+
+notify(PubBeforeAbort(request, exc_info, retry))
+
if transactions_manager:
transactions_manager.abort()
finally:
@@ -196,6 +200,9 @@
else:
# Note: 'abort's can fail. Nevertheless, we want end request
handling
try:
+
+notify(PubBeforeAbort(request, exc_info, False))
+
if transactions_manager:
transactions_manager.abort()
finally:
Modified: Zope/branches/2.12/src/ZPublisher/interfaces.py
===
--- Zope/branches/2.12/src/ZPublisher/interfaces.py 2009-11-12 21:21:32 UTC
(rev 105588)
+++ Zope/branches/2.12/src/ZPublisher/interfaces.py 2009-11-13 05:59:41 UTC
(rev 105589)
@@ -41,5 +41,12 @@
class IPubBeforeCommit(IPubEvent):
notified immediately before the transaction commit (i.e. after the main
-request processing is finished.
+request processing is finished).
+
+class IPubBeforeAbort(IPubEvent):
+notified immediately before the transaction abort (i.e. after the main
+request processing is finished, and there was an error).
+
+exc_info = Attribute('''The exception info as returned by
'sys.exc_info()'.''')
+retry = Attribute('Whether the request will be retried')
Modified: Zope/branches/2.12/src/ZPublisher/pubevents.py
===
--- Zope/branches/2.12/src/ZPublisher/pubevents.py 2009-11-12 21:21:32 UTC
(rev 105588)
+++ Zope/branches/2.12/src/ZPublisher/pubevents.py 2009-11-13 05:59:41 UTC
(rev 105589)
@@ -10,7 +10,7 @@
from zope.interface import implements
from interfaces import IPubStart, IPubSuccess, IPubFailure, \
- IPubAfterTraversal, IPubBeforeCommit
+ IPubAfterTraversal, IPubBeforeCommit, IPubBeforeAbort
class _Base(object):
PubEvent base class.
@@ -42,3 +42,10 @@
class PubBeforeCommit(_Base):
notified immediately before the commit.
implements(IPubBeforeCommit)
+
+class PubBeforeAbort(_Base):
+notified immediately before an abort.
+implements(IPubBeforeAbort)
+
+def __init__(self, request, exc_info, retry):
+self.request, self.exc_info, self.retry = request, exc_info, retry
Modified: Zope/branches/2.12/src/ZPublisher/tests/testpubevents.py
===
--- Zope/branches/2.12/src/ZPublisher/tests/testpubevents.py2009-11-12
21:21:32 UTC (rev 105588)
+++ Zope/branches/2.12/src/ZPublisher/tests/testpubevents.py2009-11-13
05:59:41 UTC (rev 105589)
@@ -8,7 +8,7 @@
from ZPublisher.Publish import publish, Retry
from ZPublisher.BaseRequest import BaseRequest
from ZPublisher.pubevents import PubStart, PubSuccess, PubFailure, \
- PubAfterTraversal, PubBeforeCommit
+ PubAfterTraversal, PubBeforeCommit,
[Zope-Checkins] SVN: Zope/branches/2.12/src/ZPublisher/Publish.py Be a bit more forceful about aborting the transaction
Log message for revision 105590: Be a bit more forceful about aborting the transaction Changed: U Zope/branches/2.12/src/ZPublisher/Publish.py -=- Modified: Zope/branches/2.12/src/ZPublisher/Publish.py === --- Zope/branches/2.12/src/ZPublisher/Publish.py2009-11-13 05:59:41 UTC (rev 105589) +++ Zope/branches/2.12/src/ZPublisher/Publish.py2009-11-13 06:42:23 UTC (rev 105590) @@ -175,12 +175,12 @@ finally: # Note: 'abort's can fail. Nevertheless, we want end request handling -try: - -notify(PubBeforeAbort(request, exc_info, retry)) - -if transactions_manager: -transactions_manager.abort() +try: +try: +notify(PubBeforeAbort(request, exc_info, retry)) +finally: +if transactions_manager: +transactions_manager.abort() finally: endInteraction() notify(PubFailure(request, exc_info, retry)) @@ -198,19 +198,19 @@ newrequest.close() else: + # Note: 'abort's can fail. Nevertheless, we want end request handling -try: - -notify(PubBeforeAbort(request, exc_info, False)) - -if transactions_manager: -transactions_manager.abort() +try: +try: +notify(PubBeforeAbort(request, exc_info, False)) +finally: +if transactions_manager: +transactions_manager.abort() finally: endInteraction() -notify(PubFailure(request, exc_info, False)) +notify(PubFailure(request, exc_info, retry)) raise - def publish_module_standard(module_name, stdin=sys.stdin, stdout=sys.stdout, stderr=sys.stderr, environ=os.environ, debug=0, request=None, response=None): ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] Zope 2.12 - one more ZPublisher event
Leonardo Rochael Almeida wrote: Wouldn't it be better to just move IPubFailure before the abort? Is there a reason for subscribing to such an event which would required the transaction to be aborted already? I can see the usefulness of the transaction being already doom()ed before this event, but not aborted. There is an IPubSuccess which runs after the transaction is closed. Doing post-processing after closure may be useful to keep transactions shorter and thus reduce the risk of conflict errors. I don't think an extra event will cost us much, so being consistent and granular is probably best. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2.12 - one more ZPublisher event
Hi, In Zope 2.12 ZPublisher we have a good set of events now, which provide useful hooks for modifying the response before or after publication. However, I'd like to add one more. ;-) Basically, we have IPubFailure, but this is sent *after* transaction.abort() and endInteraction(). This means that it's impossible to read from the ZODB when trying to deal with a failure. I'd like to add an event before that, IPubBeforeAbort, which mirrors IPubBeforeCommit in being sent before the transaction is aborted. I can do this on Zope trunk + 2.12 branch if no-one objects. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Writing output logs from zope.testing.testrunner
Martin Aspeli wrote: Hi, I'm trying to turn the results of a test run using zope.testing (zc.recipe.testrunner) into a JUnit compliant XML format so that I can graph it with Hudson (a continuous integration tool). Are there any hooks in zope.testing to write reporting to a file? I couldn't find any, so I created a new test runner which basically wraps the output formatter to capture key events. http://pypi.python.org/pypi/collective.xmltestreport I was able to use this successfully with Hudson: http://www.martinaspeli.net/articles/using-hudson-ci-for-plone-projects (this is not Plone specific and would work for anyone using zope.testing) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/2.12/ Avoid possible errors on test tear-down in Products.Five.fiveconfigure's cleanUp() function if Products.meta_types has not been set
Log message for revision 105503: Avoid possible errors on test tear-down in Products.Five.fiveconfigure's cleanUp() function if Products.meta_types has not been set Changed: U Zope/branches/2.12/doc/CHANGES.rst U Zope/branches/2.12/src/Products/Five/fiveconfigure.py -=- Modified: Zope/branches/2.12/doc/CHANGES.rst === --- Zope/branches/2.12/doc/CHANGES.rst 2009-11-06 06:23:44 UTC (rev 105502) +++ Zope/branches/2.12/doc/CHANGES.rst 2009-11-06 08:21:09 UTC (rev 105503) @@ -11,8 +11,9 @@ Bugs Fixed ++ +- Avoid possible errors on test tear-down in Products.Five.fiveconfigure's + cleanUp() function if Products.meta_types has not been set - Zope 2.12.1 (2009/11/02) Modified: Zope/branches/2.12/src/Products/Five/fiveconfigure.py === --- Zope/branches/2.12/src/Products/Five/fiveconfigure.py 2009-11-06 06:23:44 UTC (rev 105502) +++ Zope/branches/2.12/src/Products/Five/fiveconfigure.py 2009-11-06 08:21:09 UTC (rev 105503) @@ -225,7 +225,7 @@ _register_monkies = [] global _meta_type_regs -Products.meta_types = tuple([ info for info in Products.meta_types +Products.meta_types = tuple([ info for info in getattr(Products, 'meta_types', []) if info['name'] not in _meta_type_regs ]) _meta_type_regs = [] ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] Zope 2.12 and Five - setting of Products.meta_types
Martin Aspeli wrote: Hi, Something has changed in Zope 2.12 that is causing tests that use PlacelessSetup's tearDown() with Five to fail: Error in test /Users/optilude/Development/Plone/Code/Build/plone/4.0/src/plone.autoform/plone/autoform/tests/../autoform.txt Traceback (most recent call last): File /Users/optilude/.buildout/eggs/zope.testing-3.7.7-py2.6.egg/zope/testing/doctest.py, line 2416, in debug self.tearDown() File /Users/optilude/.buildout/eggs/zope.testing-3.7.7-py2.6.egg/zope/testing/doctest.py, line 2295, in tearDown self._dt_tearDown(test) File /Users/optilude/.buildout/eggs/zope.app.testing-3.6.2-py2.6.egg/zope/app/testing/placelesssetup.py, line 59, in tearDown tearDown_() File /Users/optilude/.buildout/eggs/zope.testing-3.7.7-py2.6.egg/zope/testing/cleanup.py, line 55, in cleanUp cleanUp() File /Users/optilude/.buildout/eggs/zope.testing-3.7.7-py2.6.egg/zope/testing/cleanup.py, line 63, in cleanUp func(*args, **kw) File /Users/optilude/.buildout/eggs/Zope2-2.12.1-py2.6-macosx-10.6-i386.egg/Products/Five/fiveconfigure.py, line 228, in cleanUp Products.meta_types = tuple([ info for info in Products.meta_types AttributeError: 'module' object has no attribute 'meta_types' Sure enough, Products.meta_types is not set. In the Zope2 egg, Products/__init__.py contains only the setuptools boilerplate for namespace packages. I'm not sure how or where Products.meta_type is set these days. Does anyone know how to correctly fix this? We could make the tear-down code in Five more robust, obviously, but I fear that's just hiding a deeper problem? I couldn't find a deeper problem, so I just added some safety to the cleanUp() method using getattr(). If anyone thinks this is a bad idea, let me know. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-CMF] CMF 2.2 icon_expr vs. content_icon
Hi, What's the reasoning behind having both a content_icon and an icon_expr property on FTIs in CMF 2.2? Apart from being really confusing, it seems that DynamicType.getIcon() returns fti.getIcon() (with some mangling), which returns self.content_icon. Hence, if you set an icon with icon_expr and leave content_icon, getIcon() always returns an empty string. This sounds like a bug to me, but I'm not sure how best to fix it: - remove one of content_icon and icon_expr? - make TypeInfo.getIcon() check both? If so, which takes precedence? - make Dynamictype.getIcon() check both? If so, which takes precedence? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-dev] Zope 2.12 and Five - setting of Products.meta_types
Hi, Something has changed in Zope 2.12 that is causing tests that use PlacelessSetup's tearDown() with Five to fail: Error in test /Users/optilude/Development/Plone/Code/Build/plone/4.0/src/plone.autoform/plone/autoform/tests/../autoform.txt Traceback (most recent call last): File /Users/optilude/.buildout/eggs/zope.testing-3.7.7-py2.6.egg/zope/testing/doctest.py, line 2416, in debug self.tearDown() File /Users/optilude/.buildout/eggs/zope.testing-3.7.7-py2.6.egg/zope/testing/doctest.py, line 2295, in tearDown self._dt_tearDown(test) File /Users/optilude/.buildout/eggs/zope.app.testing-3.6.2-py2.6.egg/zope/app/testing/placelesssetup.py, line 59, in tearDown tearDown_() File /Users/optilude/.buildout/eggs/zope.testing-3.7.7-py2.6.egg/zope/testing/cleanup.py, line 55, in cleanUp cleanUp() File /Users/optilude/.buildout/eggs/zope.testing-3.7.7-py2.6.egg/zope/testing/cleanup.py, line 63, in cleanUp func(*args, **kw) File /Users/optilude/.buildout/eggs/Zope2-2.12.1-py2.6-macosx-10.6-i386.egg/Products/Five/fiveconfigure.py, line 228, in cleanUp Products.meta_types = tuple([ info for info in Products.meta_types AttributeError: 'module' object has no attribute 'meta_types' Sure enough, Products.meta_types is not set. In the Zope2 egg, Products/__init__.py contains only the setuptools boilerplate for namespace packages. I'm not sure how or where Products.meta_type is set these days. Does anyone know how to correctly fix this? We could make the tear-down code in Five more robust, obviously, but I fear that's just hiding a deeper problem? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] proposal: Custom schema properties
Adam Groszer wrote: Hello, After quickly glancing over plone.behavior it seems more like something to extend a schema, and does it solve the problem of new properties -- new schema -- change everything around it? What I need is to be able to change schema properties per site. And skipping the need to fix the forms or whatever concerned with that changed schema. I'm not sure I really understand your problem (from reading the original email), but I maybe offer a few suggestions. plone.behavior is a way to create re-usable chunks of functionality. A behavior may or may not include a schema with form fields, and/or an adapter factory. When the behaviour is enabled for an instance (how it is enabled is application-specific: in Plone/Dexterity we list enabled behaviours against each content type), it will be possible to adapt an instance to the behaviour interface, and to look up the schema interface for form rendering, say. There is also a package called plone.autoform, which provides a base class for z3c.form-type forms and enables schemata to be self-describing (e.g. this field goes before that field, or this field is only shown if the user has this permission). plone.autoform interprets these schema hints to set up a suitable form. Now, in Dexterity (a content type framework for Plone) we use plone.autoform in such a way that standard add/edit forms are constructed by looking at a type's canonical schema interface + the schema interfaces (if any) of any behaviours enabled on that type. This means that we can compose types from a number of behaviours (e.g. locking, versioning, staging, multi-lingual support etc) and other things fall into place: add/edit forms, views, viewlets and so on. For your use case, I think the lessons are: - by using some kind of inversion of control on the forms and other schema-dependent things, you may be able to avoid the re-register everything problem - try to separate out the parts of the schema that are truly re-usable, and the ones that are application specific - register views/forms/whatever for the most generic schema feasible and ensure that this is provided by your instances As for your specific proposal, I'd definitely keep it in a separate package: zope.schema needs to stay simple. We also need to be very careful about the possible side-effects of mutating schemata that may be used by other things. If the code you read (interfaces.py) is out of sync with the code that's executed, we end up with confusion. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Chris Withers wrote: Martin Aspeli wrote: If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. This prints the picked versions with some explanation about what required them, either to a file or to the console. This is a useful sanity check: if you see a package in there that looks spurious you may ask whether it should've been pinned somewhere. This should really be in buildout core. Who maintains this extensions and could they be persuaded to merge it into the main code base? Mustapha Benali. See PyPI. I don't know if it needs to be in the core. Just do [buildout] extensions = buildout.dumppickedversions ... And you're done. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Jim Fulton wrote: On Wed, Oct 7, 2009 at 8:50 PM, Martin Aspeli optilude+li...@gmail.com wrote: Hanno Schlichting wrote: On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen faas...@startifact.com wrote: [ztk.cfg] contains a line allow-picked-versions = false I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it. The question though is why this is in there in the first place. Presumably it is to ensure that the *ZTK* locks down all versions. I think we can reasonably ensure this by moving the 'allow-picked-versions' to the ZTK's buildout.cfg instead, right? Yes, +1 for moving it to the buildout.cfg. If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. This prints the picked versions with some explanation about what required them, either to a file or to the console. This is a useful sanity check: if you see a package in there that looks spurious you may ask whether it should've been pinned somewhere. Running buildout in verbose mode (-v) gives you this same information. Is the idea that this information gets printed even in normal mode? Yeah: - it gets printed always, summarised at the end - it's a lot more concise than the -v output and easier to read - the output is usable as a [versions] block and can be output to a file I use a pattern where I have a devel.cfg that pins some things but allow certain dependencies to float, and then writes the versions it picks to kgs.cfg. For production deployments, there's a production.cfg which (among other things) extends this kgs.cfg. The idea is that once we have a known good configuration in development, we check that file into svn so we have a record, and make sure that absolutely everything is pinned in production. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Hanno Schlichting wrote: On Thu, Oct 8, 2009 at 2:59 PM, Martijn Faassen faas...@startifact.com wrote: Martin Aspeli wrote: If we do that, I'd also suggest we use the 'buildout.dumppickedversions' extension. Does that make sense? After all, if we say allow-picked-version is false, there never will *be* any picked versions to dump. Or am I misunderstanding something? It doesn't make sense. With allow-picked-version = false you will always get an error telling you which package and which version has been picked but wasn't pinned. Once your build succeeds buildout.dumppickedversions jumps in and will always present you with an empty list. Right, sorry, I must've been tired when I read this. In my mind, I read it as disallow-picked-versions = false. :) Given that buildout.dumppickedversions is GPL whose use is questionable in svn.zope.org, Surely, using the extension isn't an issue. It's just referenced by name and installed. That's like saying you can't use gcc (which I assume is GPL licensed) to build C extensions. I'd just stick with using allow-picked-version in buildout.cfg. Right. One is not an alternative to another. But it's useful to know what got picked, if you allow things to get picked, and it can be hard to pin everything always. Sometimes, you want to get newer versions precisely so that you can test new things without having to know that a new release is available and update your pins. Anyway, different issue. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Martin Aspeli wrote: Right, sorry, I must've been tired when I read this. In my mind, I read it as disallow-picked-versions = false. :) No, I'm not crazy after all. The thread is about *removing* allow-picked-versions=false i.e. allowing versions to be picked. I don't not hate those double negatives, dammit. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver tseaver at palladion.com writes: There is no way to tell the difference between a WebDAV GET and a normal browser GET, period: the specs explicitly, deliberately overload the GET verb. Hence the IANA-assigned WebDAV source port[1] (9800) (which *we* requested) in order to disambiguate those requests. Heh, nice. That said, though: we know which port Zope is listening to for WebDAV. Even if it's 80 or 81 or whatever, we should be able to detect a DAV request by correlating the port on which the request was received with the address of the webdav server in zope.conf. True, we probably also allow DAV over the http port, but if that's a bit broken, I don't see a huge problem telling people to use a dedicated port. Do you see any problems with this? Unfortuantely, there's no way to guarantee people will only use this port for Zope's WebDAV server. That said, the two problems (WebDAV requests result in a browserDefault lookup, and folder contents) are not really an issue in everyday use for GET request. They merely cause things to explode on PUT requests to a null resource. We *can* identify PUT requests, obviously. Strictly, PUT is not WebDAV-specific; however, it might be reasonable to apply the policy you are requesting for any PUT. True. So any comments on my proposal to skip the browserDefault lookup and the acquisition of resources for PUT/PROPFIND/PROPPATCH requests? +.5, I guess. I'd like to make sure that we aren't breaking some other use first. I'll run the tests? :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Removing zope.testrecorder from the ZTK
Benji York wrote: On Wed, Oct 7, 2009 at 1:26 PM, Thomas Lotze t...@gocept.com wrote: I just noticed that zope.testrecorder, which is listed in ztk.cfg as an included package, imports from Globals, OFS, AccessControl and Products.PageTemplates. This looks to me as if zope.testrecorder shouldn't actually be part of the ZTK. It's also not used by any package mentioned in ztk.cfg. As one of the last few people to touch zope.testrecorder I should probably speak up with some background. The package was created several years ago to experiment with writing a browser test recorder that could output either testbrowser tests or old-style functional tests. It fell into disuse from almost the start but Philipp brought it out of mothballs to cover in his book. Since then I don't know that anyone has worked on it -- or that it works at all, in fact. I don't have any problem with it being dropped from the ZTK. I know a lot of people are using testrecorder with Plone. That doesn't mean it has to be in the ZTK of course. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
Thomas Lotze wrote: - zope.contenttype: parsing of MIME-type identifiers, guessing the MIME type of file contents, preferrably without dependencies within the ZTK Can I suggest that we use a different name? 'content type' to me sounds like CMS-y functionality. We have interfaces like IContentType and methods like queryContentType, neither of which would be relevant to zope.contenttype. :) Maybe zope.mimeparsing or something like that? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
Hanno Schlichting wrote: On Tue, Oct 6, 2009 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com wrote: Thomas Lotze wrote: - zope.contenttype: parsing of MIME-type identifiers, guessing the MIME type of file contents, preferrably without dependencies within the ZTK Can I suggest that we use a different name? Please don't! We have renamed this package already way too often. This ain't funny anymore: try: from zope.contenttype import guess_content_type except ImportError: # BBB: Zope 2.10 try: from zope.app.content_types import guess_content_type except ImportError: # BBB: Zope 2.9 from OFS.content_types import guess_content_type Actually, that is kind of funny. :) But yeah, renaming is bad. I thought we were making a new package. Ignore my suggestion. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.site.hooks
Martijn Faassen wrote: We could investigate two options: * just removing that code that remove proxies and sees what happens to significant Zope 3 code bases. Risky. * alternatively, putting in an optional dependency on zope.security in zope.component. If zope.security proxy is importable, try removing the proxies, otherwise don't. Please don't add new dependencies to zope.component. Even optional ones, IMHO. It makes it harder to re-use for others and more complex to understand. Many people (e.g. those wanting to use GAE) object to the C stuff in zope.security in particular. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
Tres Seaver tseaver at palladion.com writes: There is no way to tell the difference between a WebDAV GET and a normal browser GET, period: the specs explicitly, deliberately overload the GET verb. Hence the IANA-assigned WebDAV source port[1] (9800) (which *we* requested) in order to disambiguate those requests. Heh, nice. Unfortuantely, there's no way to guarantee people will only use this port for Zope's WebDAV server. That said, the two problems (WebDAV requests result in a browserDefault lookup, and folder contents) are not really an issue in everyday use for GET request. They merely cause things to explode on PUT requests to a null resource. We *can* identify PUT requests, obviously. So any comments on my proposal to skip the browserDefault lookup and the acquisition of resources for PUT/PROPFIND/PROPPATCH requests? This is the IPublishTraverse adapter I've had to register for this stuff to work right now. As you can see, I have to undo certain things the default traversal does (nice I didn't want to copy all that code and only modify the one condition needed). http://svn.plone.org/svn/plone/plone.dexterity/trunk/plone/dexterity/browser/traversal.py (ignore the DAV_FOLDER_DATA_ID stuff - that's application specific). Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.filerepresentation release
Hi, Following an earlier discussion on this list, I've made changes to zope.filerepresentation to incorporate two new interfaces, IRawReadFile and IRawWriteFile. These allow file representation adapters which behave like Python standard library 'file' objects. This in turn allows implementation of efficient reading/writing or large files (without loading everything into memory), ZServer streaming support, and the use of file representation adapters in contexts that expect a standard file. The changes are 100% backwards compatible: they merely add two interfaces. I'd very much like a release of this. :) Would anyone mind making a 3.5.1 release, or else give me PyPI rights so that I can do it myself. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation release
Fabio Tranchitella wrote: Hello, * 2009-10-05 12:15, Martin Aspeli wrote: Would anyone mind making a 3.5.1 release, or else give me PyPI rights so that I can do it myself. Shouldn't this be 3.6.0? I don't care one way or the other. 3.6.0 is fine by me. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2 WebDAV and acquisition
Hi, In my travails through the ZPublisher and WebDAV, I've come up with another fun thing. As far as I can tell, traversal via acquisition doesn't make any sense for a WebDAV request. If I have /foo and /bar, but not /bar/foo, then traversal to /bar/foo over WebDAV should not acquire /foo and wrap it in /bar. One reason for this (apart from being utterly confusing) is that it breaks PUT requests to a NullResource: If I try to PUT to /bar/foo it should create a new object there, not overwrite /foo. There is actually some convoluted support for detecting this in ZPublisher.BaseRequest: # Note - no_acquire_flag is necessary to support # things like DAV. We have to make sure # that the target object is not acquired # if the request_method is other than GET # or POST. Otherwise, you could never use # PUT to add a new object named 'test' if # an object 'test' existed above it in the # heirarchy -- you'd always get the # existing object :( if (no_acquire_flag and hasattr(parents[1], 'aq_base') and not hasattr(parents[1],'__bobo_traverse__')): if not (hasattr(parents[1].aq_base, entry_name) or parents[1].aq_base.has_key(entry_name)): raise AttributeError, entry_name This doesn't really work, though. The object is acquired, and then all it does is to check that the PUT() method object is a true attribute of the acquired object. But even then, raising AttributeError is wrong. What should happen, I think, is that in DefaultPublishTraverse.publishTraverse() we should *not* attempt to acquire for webdav requests. Instead, we should try direct attribute access and then __getitem__() access (which is the next thing it tries after getattr() acquisition). This would then allow the folder to return a NullResource (as OFS.ObjectManager does, for example). Any objections? It's a relatively simple condition in DfaultPublishTraverse.publishTraverse(). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
Martin Aspeli wrote: Martin Aspeli wrote: Martin Aspeli wrote: Hi, In my travails through the ZPublisher and WebDAV, I've come up with another fun thing. As far as I can tell, traversal via acquisition doesn't make any sense for a WebDAV request. If I have /foo and /bar, but not /bar/foo, then traversal to /bar/foo over WebDAV should not acquire /foo and wrap it in /bar. One reason for this (apart from being utterly confusing) is that it breaks PUT requests to a NullResource: If I try to PUT to /bar/foo it should create a new object there, not overwrite /foo. There is actually some convoluted support for detecting this in ZPublisher.BaseRequest: # Note - no_acquire_flag is necessary to support # things like DAV. We have to make sure # that the target object is not acquired # if the request_method is other than GET # or POST. Otherwise, you could never use # PUT to add a new object named 'test' if # an object 'test' existed above it in the # heirarchy -- you'd always get the # existing object :( if (no_acquire_flag and hasattr(parents[1], 'aq_base') and not hasattr(parents[1],'__bobo_traverse__')): if not (hasattr(parents[1].aq_base, entry_name) or parents[1].aq_base.has_key(entry_name)): raise AttributeError, entry_name This doesn't really work, though. The object is acquired, and then all it does is to check that the PUT() method object is a true attribute of the acquired object. But even then, raising AttributeError is wrong. What should happen, I think, is that in DefaultPublishTraverse.publishTraverse() we should *not* attempt to acquire for webdav requests. Instead, we should try direct attribute access and then __getitem__() access (which is the next thing it tries after getattr() acquisition). This would then allow the folder to return a NullResource (as OFS.ObjectManager does, for example). Any objections? It's a relatively simple condition in DfaultPublishTraverse.publishTraverse(). Actually, I found some code that may be trying to address this (although I think it's probably likely that not attempting to acquire in the first place is better). Basically, it allows acquisition during traversal, but when you get to the end of the path, it does this: if (no_acquire_flag and hasattr(object, 'aq_base') and not hasattr(object,'__bobo_traverse__')): if object.aq_parent is not object.aq_inner.aq_parent: from webdav.NullResource import NullResource object = NullResource(parents[-2], object.getId(), self).__of__(parents[-2]) This would fix the problem, except in my case, the traversed-to object (/foo in the example above) happens to have a __bobo_traverse__(), as do all CMF types, so the third caluse of the first if statement is false. I can't see the logic here, though: why would it matter if the acquired object happens to have a __bobo_traverse__? Removing that condition fixes it for me. This would be an even simpler bug fix (though I still find it fishy that you can acquire folders through WebDAV). Can anyone explain why that condition is there? Otherwise, I'll rip it out. ;-) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book Martin Aspeli wrote: Hi, In my travails through the ZPublisher and WebDAV, I've come up with another fun thing. As far as I can tell, traversal via acquisition doesn't make any sense for a WebDAV request. If I have /foo and /bar, but not /bar/foo, then traversal to /bar/foo over WebDAV should not acquire /foo and wrap it in /bar. One reason for this (apart from being utterly confusing) is that it breaks PUT requests to a NullResource: If I try to PUT to /bar/foo it should create a new object there, not overwrite /foo. There is actually some convoluted support for detecting this in ZPublisher.BaseRequest: # Note - no_acquire_flag is necessary to support # things like DAV. We have to make sure # that the target object is not acquired # if the request_method is other than GET # or POST. Otherwise, you could never use # PUT to add a new object named 'test' if # an object 'test' existed above it in the # heirarchy -- you'd always get the # existing object :( if (no_acquire_flag and hasattr(parents[1], 'aq_base') and not hasattr(parents[1],'__bobo_traverse__')): if not (hasattr(parents[1].aq_base, entry_name) or parents[1].aq_base.has_key(entry_name)): raise AttributeError, entry_name This doesn't really work, though. The object is acquired, and then all
Re: [Zope-dev] Zope 2 WebDAV and acquisition
Shane Hathaway shane at hathawaymix.org writes:
Martin Aspeli wrote:
Can anyone explain why that condition is there? Otherwise, I'll rip it
out.
As I recall, this code is convoluted because it's hard to tell whether
an HTTP request is a WebDAV request. If there is now a way to clearly
distinguish WebDAV requests, then I imagine this code can be greatly
simplified. This code had to deal with Windows 95 and such.
Well, at the very least, you can use the check that says:
if request.maybe_webdav_client and \
request['HTTP_REQUEST_METHOD'] not in ('GET', 'POST'):
This wouldn't solve the problem for WebDAV GET or POST requests, but that's
actually fine. The problem seen here mainly pertain to PUT and PROPFIND
requests.
This would meant that there's a chance people could get a weird acquisition
chain on a GET request that then wouldn't resolve properly (giving a 404) on a
subsequent PROPFIND or PUT, but this is very unlikely to happen in practice
unless someone (a) overrode listDAVObjects() to return acquired objects or (b)
manually entered a WebDAV URL that resulted in acquisition, and which was only
used for a GET.
Compared to the situation right now where PUT is broken for any file that has
the same name as an object higher up in the acquisition chain, not supporting
these arguably-invalid edge cases seems a lot better. :)
Martin
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2, WebDAV and browser-default
Hi, I came across this trying to implement WebDAV support for some content in Zope 2. The ZPublisher will always traverse to the return value from 'browserDefault()' (either from a custom IBrowserPublisher adapter, or the DefaultPublishTraverse object hardcoded in ZPublisher.BaseRequest) when it gets to the end of a traversal chain, even for WebDAV requests. This makes it impossible to e.g. get a folder listing in WebDAV. The default 'browserDefault()' will call __browser_default__() on the context if that exists. If not, it will call queryDefaultView(), which returns a view name as set by a browser:defaultView / directive, and return that name unless it is None. The publisher will then traverse to the name indicated. This breaks WebDAV in two ways: Consider a folder /foo/bar. The class for 'bar' does not implement __browser_default__(), but there is a default view, set with the browser:defaultView / directive, called 'index'. Let's say the WebDAV client attempts to do a PROPFIND request to list the folder's contents. The publisher will traverse to /foo/bar and then look up the default view, @@index, and attempt to traverse to that. This doesn't have the PROPFIND() verb method, obviously, since views don't derive from webdav.Resource, and so the WebDAV requests fails. Even if it does, there's some code at the end of BaseRequest.traverse() which checks that the last item in the traversal chain is *not* acquired (i.e. it's a genuine child of the aq_base'd second-to-last item). This is to allow PUT'ing to a name that could've been acquired (via the NullResource mechanism). This means that if you have registered a browser:defaultView / for an object, it is impossible for that object to participate in WebDAV requests. We never noticed in Plone before, because most Plone content implements __browser_default__ so that it delegates to PloneTool.browserDefault() which aborts immediately if it detects a WebDAV request. The default behaviour does *not* do this, however, and it seems wrong to expect everyone who implements __browser_default__ or an IBrowserPublisher adapter to have to do so. My suggestion would be that we simply skip the browserDefault() lookup for WebDAV requests. I don't think it's meaningful to have a browser-default page when looking at objects via WebDAV at all. I can make the change as a bugfix to 2.10, 2.11 and 2.12 if no-one objects. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope2.zope.org launched
Andreas Jung wrote: I am pleased to announce the launch of a new website dedicated to the Zope 2 application server: zope2.zope.org This site gives the Zope 2 application a much better representation on the web (which was more than necessary after having lived for years with the current old www.zope.org site). zope2.zope.org is not a community site. You will not be able to register or upload personal content (use www.zope.org for the time being). We will publish content on request (events, news etc.) - please contact the webmaster in such a case. It took more than half a year in order to get this site done and I would like to thank the following people for their involvement in this project: - Alma Ong (Design) - Robert Rottermann and Gerhard Hug (implementation of the Plone theme) - Jens Vagelpohl (server setup, technical support, content review) - Matthew Wilkes (content review) - Sidnei da Silva (moving Zope 2 downloads to Launchpad) - Michael Haubenwaller (the Zope webmaster) Andreas Jung Zope 2 Release Manager Fantastic stuff! :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation
Hanno Schlichting wrote: On Thu, Oct 1, 2009 at 2:13 AM, Martin Aspeli optilude+li...@gmail.com wrote: Hanno Schlichting wrote: Is there any reason to invent a new API and not just use Python's file API? I don't know. IReadFile and IWriteFile have been around for ever and are used by a number of things in Zope. They have read(), write() and size(). The first two are on file, the last one isn't. I'd like to be able to use this API as a base, since it's used for things like z3c.blobfile already, and is documented as the way to do this kind of thing in Philipp's book. Ok. I have a feeling that Zope3 at various times invented a new Java-ish API instead of using standard Python protocols. I'd just like to avoid going down that way even more. class IReadFile(Interface): Provide read access to file data def read(): Return the file data as a str def size(): Return the data length This needs a clarification on what kind of length this is. Is it the length of the binary data? Since these interfaces also know about encoding, it's otherwise not clear if the size for textual data might be its Unicode length. I assume so. Note that this interface already exists, so I'm not proposing to change it. ;-) class ILargeReadFile(IReadFile): Provide efficient read access to file data def getContentType(): Get the content/MIME type of the file as a string in the form 'major/minor'. Return None if this is not known or undefined. name = schema.TextLine(title=uFilename, readonly=True) encoding = schema.ASCIILine(title=uEncoding, readonly=True) encoding only makes sense for text/*, so maybe some small hint at that? Sure, yeah. def __iter__(): Get an iterator def next(): See file def seek(): See file def tell(): See file class IWriteFile(Interface): def write(data): Update the file data class ILargeWriteFile(IWriteFile): def write(data): Write a chunk of data name = schema.TextLine(title=uFilename, readonly=False) encoding = schema.ASCIILine(title=uEncoding, readonly=False) def tell(): See file def close(): See file I've still got the content type as a method (maybe make it a read-only property?) that may return None. That could be in a separate adapter, but that feels like overkill to me. :) There's no standard way to spell content type, so I don't really care. On the pure file level it's even called mime type and only internet data handling uses content type. So you have to look things up anyways. Compared to the other attributes/methods getContentType looks like a Java-intruder in otherwise Python naming conventions, though. Haha. Maybe I'll have a property mimeType instead? That looks better, I guess. But we *are* in a Zope package, so Zope naming conventions probably apply. Ok, I'm going to do this shortly, unless anyone objects. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.filerepresentation
Hi, I'm doing some work with WebDAV representations in Zope 2, among other things, and I'm trying to see if we should use zope.filerepresentation as the central abstraction for file read/write operations. However, I find myself lacking a couple of things: 1) A way for an IReadFile to return the file's MIME (content) type (for the Content-Type, for example) and an optional filename (for the Conent-Disposition header, for example) 2) A way for an IWriteFile to be told about the MIME type and encoding of the data it is consuming. I know that IFileFactory() contains this, but data is not always going to be written to a new file, so setting this from the factory won't work. 3) I see this comment: # TODO: We will add ILargeReadFile and ILargeWriteFile to efficiently # handle large data. But it seems this was never implemented. I need a way for the IWriteFile.write() to be passed a file-like object (in fact, there's not really any clear notion of what the 'data' parameter is, but I assume it's meant to be a str object), and for IReadFile.read() to return a file stream iterator of some kind instead of the full raw data. I see two options here: - add a new plone.filerepresentation that extends these interfaces - commit some changes to zope.filerepresentation and make a new release of this Since zope.filerepresentation is really *just* interfaces, #2 seems best. Any objections? Here's an initial take on the interfaces: class IReadFile(Interface): Provide read access to file data def read(): Return the file data as a str def size(): Return the data length class ILargeReadFile(IReadFile): Provide efficient read access to file data def getContentType(): Get the content/MIME type of the file as a string in the form 'major/minor'. Return None if this is not known. def getFilename(): Get the intended file name for this file. Return None if this is not known. def getIterator(): Return an iterable of the file data class IWriteFile(Interface): def write(data): Update the file data class ILargeWriteFile(IWriteFile): def writeFile(data, contentType=None, encoding=None): Update the file data. data is a file-like object containing input data contentType is the content/MIME type of the data as a string in the form 'major/minor'. It may be None if unknown. encoding is the encoding of the string. It may be None if unknown. This should be 100% backwards compatible. The downside is that people will need to implement both write() and writeFile() / read() and getIterator() to support both str based and stream based reading and writing, but that's easily addressed with a StringIO. And of course, nothing in the ZTK will actually use these new interfaces, but that could come later. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation
Hanno Schlichting wrote: Is there any reason to invent a new API and not just use Python's file API? I don't know. IReadFile and IWriteFile have been around for ever and are used by a number of things in Zope. They have read(), write() and size(). The first two are on file, the last one isn't. I'd like to be able to use this API as a base, since it's used for things like z3c.blobfile already, and is documented as the way to do this kind of thing in Philipp's book. So .name instead of getFilename, iterator per __iter__ and next? Yeah, that's a better idea. I'm not sure about the different read/write methods on file-objects, but I think the standard ones do cover all the same use-cases. The standard file implementation has no knowledge of its size, as this is sometimes impossible to get, when dealing with stream based file-like objects. Do we really need to have files to know their size? Well, for the writeFile() stuff maybe we don't. Thinking through my use cases again, I can't see a need for passing the content type in, and encoding can be set if we support setting the '.encoding' property. It's kind of important to be able to indicate the size and MIME type for a read operation, though. In this case, I want to be able to put that information into the Content-Type and Content-Length headers. The IStreamData stuff in Zope 2 also wants to know the length before it starts streaming. In some cases, it may not be possible to know, in which case we can fall back on len(data), but in other cases, the length is known (plone.namedfile and z3c.blobfile keep track of it, for example), in which case having a way to ask the adapter means it can be done much more efficiently. So, how about this: class IReadFile(Interface): Provide read access to file data def read(): Return the file data as a str def size(): Return the data length class ILargeReadFile(IReadFile): Provide efficient read access to file data def getContentType(): Get the content/MIME type of the file as a string in the form 'major/minor'. Return None if this is not known or undefined. name = schema.TextLine(title=uFilename, readonly=True) encoding = schema.ASCIILine(title=uEncoding, readonly=True) def __iter__(): Get an iterator def next(): See file def seek(): See file def tell(): See file class IWriteFile(Interface): def write(data): Update the file data class ILargeWriteFile(IWriteFile): def write(data): Write a chunk of data name = schema.TextLine(title=uFilename, readonly=False) encoding = schema.ASCIILine(title=uEncoding, readonly=False) def tell(): See file def close(): See file It may be worth supporting the rest of the functions (readlines, writelines, truncate, readline, isatty, fileno, flush) so that ILargeReadFile + ILargeWriteFile are equivalent to file. I've also allowed here for the name and encoding to be set on an ILargeWriteFile, with the caveat that this has to be done before the writing. In this approach, the caller is responsible for writing large streams in chunks and then calling close, i.e. the iterator isn't passed to the ILargeWriteFile. I think that's OK, though. I've still got the content type as a method (maybe make it a read-only property?) that may return None. That could be in a separate adapter, but that feels like overkill to me. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] Products namespace for eggs
Jens Vagelpohl wrote: On Sep 24, 2009, at 15:16 , Maurits van Rees wrote: Personally, I am the maintainer of Products.Poi. It will take more than one bottle of whisky to convince me to rename that. ;-) Personally, I believe most product authors who have a real Zope 2 Product but chose a name other than Products.XXX did so mostly because... - they think it looks cooler somehow - vanity - just because I can I doubt any of them can provide any real tangible benefits gained for users, developers or themselves. This has been revisited so many times I'm sick of re-iterating Plone's reasons for doing this. None of the above, I'm afraid. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-dev] ZTK version numbering and Zope 2.12
Hi, - What is the current version of ZTK? 1.0? 1.0-something? 3.5? Note that docs.zope.org/zopetoolkit talks about 3.5. - What is the canonical location of a ZTK KGS? I'm locking for a buildout [versions] block in particular. - What is the plan for Zope 2.12 final? Is it going to rely on some release of the ZTK, or just its own mix of versions? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] plone.z3cform: ExtensibleForm should not change groups class attribute
Gerhard Weis wrote: Hi, Sorry if this is the wrong list, but as plone.z3cform is in the zope-svn. I thought it may be Ok. There is a small problem in plone.z3cform. The class plone.z3cform.fieldsets.extensible.ExtensibleForm has a class attribute groups, which is changed by the provided API methods. I don't think this is intentional, becuase it makes it hard to recreate additional instances of ExtensibleForm. The current behaviour works for forms which use already groups, but for forms, where the EtensibleForm creates new groups on the fly, it does not work. The attached patch fixes this. It also includes a small addition to the Readme, which failes without the patch applied, and runes clean with the patch applied. Modify the class variable is certainly not intentional. It is supposed to copy it to an instance variable. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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.testing 3.8 fails in mysterious ways
Christian Theune wrote: On 08/01/2009 01:35 AM, Godefroid Chapelle wrote: Sidnei da Silva wrote: On Thu, Jul 30, 2009 at 9:33 PM, Martin Aspelioptilude+li...@gmail.com wrote: Unfortunately, I've got other packages that depend on a newer zope.testing (specifically, collective.testcaselayer). But I thought zope.testing aimed to be able to run any valid tests, so it sounds like a bug in zope.testing regardless, at least since every other test I've run in the same instance work fine. The traceback you pasted shows an UnboundLocalError. What about looking at the source and figuring out why that local variable is not defined? -- Sidnei I bumped into the same bug while working on the same package... I allowed myself to add the missing assignment. However, I'd like someone to check over my shoulder. http://mail.zope.org/pipermail/checkins/2009-July/036586.html Further, this bug is triggered by another one happening when running tests with buildout in plone.z3cform current trunk (r102411). The test runner is trying to spawn a subprocess with the --resume-layer argument. However, the --resume-layer argument is not accepted by the subprocess. This produces an error in a format not foreseen by the error parser. (which then triggered the UnboundLocalError). It would be nice if someone with a better understanding of the testrunner could take a look and understand why the --resume-layer stuff happens. Christian ? Can you make a bug out of that? I won't be able to look at it for a while but I'd also not have it forgotten. Sure. https://bugs.launchpad.net/zope3/+bug/407916 Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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.testing 3.8 fails in mysterious ways
Sidnei da Silva wrote: On Thu, Jul 30, 2009 at 9:33 PM, Martin Aspelioptilude+li...@gmail.com wrote: Unfortunately, I've got other packages that depend on a newer zope.testing (specifically, collective.testcaselayer). But I thought zope.testing aimed to be able to run any valid tests, so it sounds like a bug in zope.testing regardless, at least since every other test I've run in the same instance work fine. The traceback you pasted shows an UnboundLocalError. What about looking at the source and figuring out why that local variable is not defined? 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] zope.testing 3.8 fails in mysterious ways
Hi, I'm running the plone.z3cform tests in a Zope 2.10 instance with zope.testing 3.8 installed. All other tests seem to work OK, but with plone.z3cform's tests, I get: $ ./bin/instance test -s plone.z3cform Running tests at level 1 Running plone.z3cform.testing_zcml_layer tests: Set up plone.z3cform.testing_zcml_layer in 0.972 seconds. Running: .. Ran 26 tests with 0 failures and 0 errors in 0.219 seconds. Running zope.testing.testrunner.layer.UnitTests tests: Tear down plone.z3cform.testing_zcml_layer ... not supported Exception in thread Thread-1: Traceback (most recent call last): File /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py, line 442, in __bootstrap self.run() File /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py, line 422, in run self.__target(*self.__args, **self.__kwargs) File /Users/optilude/.buildout/eggs/zope.testing-3.8.0-py2.4.egg/zope/testing/testrunner/runner.py, line 418, in spawn_layer_in_subprocess while nfail 0: UnboundLocalError: local variable 'nfail' referenced before assignment Total: 26 tests, 0 failures, 0 errors in 5.626 seconds. The tests are here: http://svn.zope.org/repos/main/plone.z3cform/trunk/plone/z3cform/tests.py Any ideas? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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.testing 3.8 fails in mysterious ways
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Hi, I'm running the plone.z3cform tests in a Zope 2.10 instance with zope.testing 3.8 installed. All other tests seem to work OK, but with plone.z3cform's tests, I get: $ ./bin/instance test -s plone.z3cform Running tests at level 1 Running plone.z3cform.testing_zcml_layer tests: Set up plone.z3cform.testing_zcml_layer in 0.972 seconds. Running: .. Ran 26 tests with 0 failures and 0 errors in 0.219 seconds. Running zope.testing.testrunner.layer.UnitTests tests: Tear down plone.z3cform.testing_zcml_layer ... not supported Exception in thread Thread-1: Traceback (most recent call last): File /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py, line 442, in __bootstrap self.run() File /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py, line 422, in run self.__target(*self.__args, **self.__kwargs) File /Users/optilude/.buildout/eggs/zope.testing-3.8.0-py2.4.egg/zope/testing/testrunner/runner.py, line 418, in spawn_layer_in_subprocess while nfail 0: UnboundLocalError: local variable 'nfail' referenced before assignment Total: 26 tests, 0 failures, 0 errors in 5.626 seconds. The tests are here: http://svn.zope.org/repos/main/plone.z3cform/trunk/plone/z3cform/tests.py Any ideas? I would just use the version of zope.testing which shipped with Zope 2.10? That would be 3.0, I think: $ svn propget svn:externals \ projects/Zope-CVS/Zope-2.10-branch/lib/python/zope | grep testing testing \ svn://svn.zope.org/repos/main/zope.testing/tags/3.0/src/zope/testing Unfortunately, I've got other packages that depend on a newer zope.testing (specifically, collective.testcaselayer). But I thought zope.testing aimed to be able to run any valid tests, so it sounds like a bug in zope.testing regardless, at least since every other test I've run in the same instance work fine. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] ZopeTestCase and interactions
Hi, It seems that an integration test written using ZopeTestCase (and PloneTestCase) does not support using zope.security.checkPermission(). The problem is that the interaction threadlocal isn't set up, so you get an AttributeError. It's easy to fix: just call Products.Five.security.newInteraction() before the test is run. Is this something that should go into ZopeTestCase's setUp()? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Integrating Five code properly into Zope2?
Hanno Schlichting wrote: Hi. I'd like to push code and ZCML from Products.Five into the appropriate places in Zope2. For example event.zcml registering events for OFS items, should live in the OFS package. i18n.zcml setting up stuff for the request or the publisher should live in the ZPublisher package, security bridging code for zope.security vs. AccessControl should go into AccessControl, test setup and support code should live in Testing, ... startup code and site.zcml handling should live in the Zope2.Startup package and so on. There's probably some bridging code left in Five which has no real place to go in Zope2. Like formlib wrapping / bridging code - I'd leave this in Five for the time being until we get a clearer picture of what is actually left in there. Given our current deprecation policy, I'd leave indefinite backwards compatibility imports in place and do the same for ZCML files. It would be work targeted at the lucky numbered Zope 2.13 ;-) Do people generally agree with this direction? +1 Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] ZopeTestCase and interactions
Hanno Schlichting wrote: On Sun, Jul 26, 2009 at 5:21 PM, Martin Aspelioptilude+li...@gmail.com wrote: The problem is that the interaction threadlocal isn't set up, so you get an AttributeError. It's easy to fix: just call Products.Five.security.newInteraction() before the test is run. Is this something that should go into ZopeTestCase's setUp()? The ZopeTestCase classes themselves don't set up any of the ZCML structure right now and I'd like to keep it that way. True. This isn't a ZCML, thing, though. :) Isn't the placeless layer exactly for this use-case of getting some minimal integration fixture set up? Since Zope 2.12 a Zope2 specific version of that is in Testing.ZopeTestCase.placeless. Before you would get it from zope.app.testing.placelesssetup. I see. That sounds like a sensible place. My main aim is that when you use a PloneTestCase, you should get the interaction set up so that calls to zope.security.checkPermission() don't fail. Does PTC and other similar things set up the placeless layer? Or something like it? The module in Testing.ZopeTestCase uses from zope.security.management import newInteraction though and not Five. Maybe it should use the Five version instead? Almost certainly. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] How to test changes to ZTK packages?
Wichert Akkerman wrote: On 6/30/09 7:03 PM, Stephan Richter wrote: It is needed for the latest-versions script as this parses XML. I consider lxml pretty much the standard tool to do XML in Python these days. Who is not using lxml? I suspect the majority of people who use OSX as their main platform try to stay as far away from lxml as possible. Not because lxml is bad, but because unless you use special magic it will make your python randomly segfault. This is very sad, and it is not lxml's fault but I see no good solution at this moment. There is a good solution: binary eggs. lxml already does this for Windows, and we're about to get them for OS X. So I think lxml will again become a reasonable thing to depend on. Which is important, because it's a very good library. Using z3c.recipe.staticlxml recipe helps a bit for people using buildout, but that is not everyone and even then I have seen random segfaults. I've never seen errors with a static build (although I've seen the recipe fail to remove a non-static egg in a shared eggs cache). Maybe I'm lucky. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] zope.proxy
Hi, Is there any documentation on zope.proxy other than the test? I don't speak C anymore. :) Basically, I'm curious if it would be possible to implement translation proxies that would allow getting and setting translated values for certain fields. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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.proxy
Hi Christian, Thanks for this! Have a look at the attached file, it contains the code that I extracted from a project in a hurry, but if the approach sounds reasonable to you, I'd be happy to put that into SVN. Can you tell me a bit more about how this is hooked into publication? Where do you create the Translation object? How do you look up translations later and present the correct translation to users? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] REQUEST vs. request
Patrick Gerken wrote: Hello, I am a bit confused about self.request and self.REQUEST. Can anybody point me to an explanation of the different tasks that both have? Googling for request vs REQUEST is not helpful... D'oh! :-) REQUEST is a Zope2-ism. When you do self.REQUEST somewhere, you are actually using acquisition to get this object from the outermost item in any (most?) acquisition chain: a magic RequestContainer class whose purpose it is to let you acquire a REQUEST. In general, this is a bit icky. You probably should avoid it. self.request is not generally available. Rather, it's the most commonly used name for the request stored on an attribute in a view or viewlet. These are initialised with a context and a request (and view and viewlet manager in the case of a viewlet), and normally store those as self.context and self.request. In Zope 2, your views *also* support acquisition, because until Zope 2.12 at least, they have to in order to have security. So you can do self.REQUEST on the view, which acquires it from a parent. But this is magic and you shouldn't do it if you can avoid it. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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.buildout problem
Maurits van Rees wrote: Adam GROSZER, on 2009-05-24: Hello, Following just happened. The project has KGS 3.4 versions as a base, locally I wanted to override lxml to = 2.1.1. [...snip...] extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg versions = versions [versions] lxml = 2.1.1 Only assignment (=) is allowed here, not comparison (=). Right. And note that it's =, not ==. A [versions] block is not a version spec, it's an explicit pin. You may also be interested in the buildout.dumppickedversions, which helps you analyse what buildout actually picked, and possibly in http://good-py.appspot.com, which helps you manage version pins in different layers for different platforms. For example, you could add a second line to 'extends' with another KGS layered on top of the Zope 3.4.0 one, overriding some versions and adding others. Comparison is allowed in a few other spots, for example: recipe = my.recipe.name = 1.0 And in any 'eggs' line. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Another OFS.Traversable and ZPublisher inconsistency
Hi, So, we determined that OFS.Traversable's unrestrictedTraverse() shouldn't grow support for IPublishTraverse, which is fair enough. We're now using an ITraversable adapter instead (++namespace++). However, we found another inconsistency. In URL traversal, this works: /foo/bar/++namespace++/123 In OFS.Traversable, it doesn't, but this does: /foo/bar/++namespace++blah/123 The reason is that in restrictedTraverse(), we have this check: if name and name[:1] in '@+' and name != '+' and nsParse(name)[1]: ns, nm = nsParse(name) However, nsParse(name)[1] is '' if no name is provided after the namespace. In BaseRequest.traverseName() we have a similar, but more relaxed check: if name and name[:1] in '@+' ns, nm = nsParse(name) if ns: ... This also has the advantage of not calling nsParse() twice. I can't understand why OFS.Traversable would explicitly disallow namespace traversal with an empty string as the name. Is this on purpose, or a bug? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Why does restrictedTraverse() in Zope 2 not respect IPublishTraverse adapters?
Jan Hackel wrote:
Some days ago I ran into the same problem, and have been pointed to this
thread. Maybe you are interested in my solution. It's ugly, but I needed it
for a test-case, where I wanted to access
@@plone_context_state/is_view_template:
from ZPublisher.HTTPRequest import HTTPRequest
from ZPublisher.HTTPResponse import HTTPResponse
from Products.PloneTestCase import PloneTestCase
import base64
user_id = PloneTestCase.default_user
password = PloneTestCase.default_password
encoded = base64.encodestring( '%s:%s' % ( user_id, password ) )
auth_header = 'basic %s' % encoded
resp = HTTPResponse()
env={'SERVER_URL':'http://nohost/plone',
... 'URL':'http://nohost/plone',
... 'HTTP_AUTHORIZATION': auth_header,
... 'REQUEST_METHOD': 'GET',
... 'steps': [],
... '_hacked_path': 0,
... '_test_counter': 0,
... }
request = HTTPRequest(stdin=None, environ=env, response=resp)
request['PARENTS'] = [self.getPortal()]
contextState = request.traverse(weblog/issue193/
... @@plone_context_state)
request['ACTUAL_URL'] = 'http://nohost/weblog/issue193'
contextState.is_view_template()
True
request.close()
For this, you should possibly use zope.testbrowser (and
Products.Five.testbrowser).
The reason you needed this particular hack was that the
is_view_template() method looks at the url quite specifically. For most
cases, context.restrictedTraverse('@@plone_context_state') would've worked.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
Zope-Dev maillist - Zope-Dev@zope.org
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] Why does restrictedTraverse() in Zope 2 not respect IPublishTraverse adapters?
Hi,
There's currently a funny inconsistency in Zope's Traversable class. If
you have a URL like http://localhost:8080/path/to/@@aview/foo, and
@@aview implements IPublishTraverse (and, I presume, if there's a custom
IPublishTraverse adapter for any other path component), URL traversal
will work fine, but calling to.restrictedTraverse('@@aview/foo') or some
variant thereof will fail, because (un)restrictedTraverse() does not
respect custom IPublishTraverse adapters.
I can kind of see why it's done like this since it's called
I*Publish*Traverse, but it is a pain.
Note that namespace traversal (like ++skin++) works fine with
restrictedTraverse().
I don't think it'd be hard to implement this, but:
- is this a bug?
- is there a reason not to do this?
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
Zope-Dev maillist - Zope-Dev@zope.org
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] dropping Python 2.4 support in the Zope Toolkit?
Tres Seaver wrote: The burden of proof *is* the work you just signed up the preserve 2.4 group for: monitoring the packages they care about for things which break under 2.4, and proposing 2.4-compatible fixes. Sure. That's different to saying officially that ZTK does not support Python 2.4, though, which is where we were going before. Note as well that the mere presence of certain kinds of BBB code is a burden on the core maintainers. Conditional imports, for instance, create untestable code paths, as do other kinds of capability checks. Removing that kind of cruft increases the quality of the codebase, at the expense of backward compatibility. Agree. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] dropping Python 2.4 support in the Zope Toolkit?
Martijn Faassen wrote: Hey, Martijn Faassen wrote: In order to get to a conclusion: I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries. I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden. Since I haven't seen such arguments besides the Plone 3.x related ones, I will amend the zope toolkit decisions about this. We've had some more discussions about this and the Plone release schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, it will effectively render it inaccessible to Plone users for the next 12-18 months. We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear. That makes the potential user base for new-and-dependency-isolated Zope components quite a bit smaller. I agree that some of the refactored ZTK components don't make sense if they're bundled with Zope 2.10 in pre-refactored form. However, the idea is surely also to support new and more focused components in the toolkit. At the end of the day, it may not make much of a difference. However, I am still puzzled as to why we you are trying to base a decision on arguments *against* breaking compatibility. The main argument *for* dropping compatibility seems to be a hand-wave towards an added maintenance burden. Is that really so? Are we struggling to release components that work across Python versions? If there are Python 2.5 features we really want to use, then I understand. Otherwise, I think as a general principle it makes sense to always aim for the widest amount of compatibility possible, at least when it comes to the core Zope Toolkit, which, by its very nature, aims to underpin a number of heterogeneous platforms with different constraints. I'd rather hope Plone was considered one of those platforms. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] dropping Python 2.4 support in the Zope Toolkit?
Lennart Regebro wrote: On Tue, May 5, 2009 at 11:55, Martin Aspeli optilude+li...@gmail.com wrote: We've had some more discussions about this and the Plone release schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, it will effectively render it inaccessible to Plone users for the next 12-18 months. We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear. Can you expand on this argument, because I don't understand it. Zope 2.10 doesn't stop working because Zope 2.12 no longer supports Python 2.4. And you are not expected to use Zope Toolkit with Zope 2.10, as Zope 2.10 uses Zope 3.3 rather than Zope Toolkit. - I think that as a principle, dropping support for a Python version that's commonly used in our community, should be a decision that requires a strong argument *for*, not a strong argument *against*. - The Zope Tool Kit aims to be a bridge between our different communities, and possibly other communities that may want to consume Zope software (are all of those using Python 2.5?). That means that those of us who are not in a position to move to Python 2.5+ soon deserve to be heard. Of course, Plone's point of view shouldn't be overriding to other concerns, but see point 1. - If you count the Zope community as those who also maintain Zope 2, we need to recognise that there's been no viable way for Plone to get to Python 2.5 until now, and the other changes in 2.12 mean it's not feasible to upgrade to it in the 3.x series. This is nobody's fault, of course, but it does leave a chasm that'll only widen as time goes on. - Once the ZTK is decreed to no longer need to support Python 2.4, I suspect no new development on the Zope platform will bother with it either. That means users of Plone can't use these packages. That in turn deprives those Zope packages of testers and potential contributors. - We are using Zope 3.4+ packages successfully with Zope 2.10 right now. I don't see that the ZTK will be any different. In fact, ZTK should help here, because we're getting a saner dependency structure. The Plone community is working hard to move to Python 2.5, but reality is we won't get there for another 12-18 months, in part because Zope 2.12 is only now entering alpha and incorporates a lot of other (good!) changes that we need more time to integrate and work out a migration story for. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] dropping Python 2.4 support in the Zope Toolkit?
Martijn Faassen wrote: As I pointed out, it is effectively inaccessible for Plone users anyway, as Zope 3 is already installed. You *cannot* mix Zope Toolkit and Zope 3 libraries just like that and expect anything to work. Why not? We upgrade Zope 3.3 packages to 3.4+ all the time to access bug fixes or new features. It's rarely completely painful, but once you've got an understanding of what versions work and don't work together, you do have the option of selectively upgrading parts of the zope.* namespace. Also, I'm expecting there to be completely new packages that are not a like-for-like replacement of the Zope 3.3 set. Whether these would work is of course a case-by-case evaluation. But let's not make it a no by default, unless there's a good reason. There are no such new and more focused components even on the drawing board yet. I highly doubt that the first release of the Zope Toolkit will contain such components. What about packages that build on the ZTK? Stephan just gave a great example with z3c.form. Surely, that's the kind of innovation and code sharing we want to encourage. We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear. That makes the potential user base for new-and-dependency-isolated Zope components quite a bit smaller. I don't believe in this Plone (for *existing Plone releases*) user base anyway, so I don't think it's getting smaller. I think you're wrong about that. For example, the known-good-set of packages required to get Dexterity 1.0a1 to install on Plone 3.3 will look something like this: http://good-py.appspot.com/release/dexterity/1.0a1?plone=3.3rc2 Most of the zope.* upgrades there are caused by a z3c.form dependency, plus z3c.relationfield. If we'd have released a Zope 3.5 that didn't have Python 2.4 support, would you have complained that you cannot use Zope 3.5 with an existing Plone release? Yes. This is the same as trying to use Zope 3.4 and Zope 3.3 components together (though the changes from Zope 3.4 to the Toolkit are *bigger* as we move things around). It *might* just work in some cases, but it's unlikely it will. It does. ;) And Plone is likely to see Zope 2.11 (which uses Zope 3.4) before 2.12. As far as I know, Zope 2.11 is still supported only on Python 2.4, but being based on Zope 3.4, we are much closer to ZTK as a starting point. Typically, there'll be three reasons to upgrade packages: - either, we depend on a bug fix (quite common, e.g. with zope.i18n) - or, we depend on a package that depends on a newer version of a core package that's backwards compatible (c.f. z3c.form) - or, we need a new feature (less common, in practice) Sorry, I won't let you turn this back around again. :) Arguments for increased maintenance burden will need to be realistic. What is the increased burden? I mean, are we feeling this pain today? Do we have evidence that we'll be feeling it going forward? I'm not saying your argument is invalid - instinctively, it makes a lot of sense. But it feels like we're taking that argument for granted with little actual evidence and justification, and ignoring the counter-argument as invalid, which makes this conversation a bit difficult to have. I will note that Grok 1.0 won't work with the Zope Toolkit either; we're sticking with Zope 3.4. Only after 1.0 will we go over to the toolkit. Right. And Plone won't ship with ZTK by default for a while yet, I reckon, but we want people to be able to use the new code and experiment with it early and often. It is, but again, it's just wishful thinking that the toolkit libraries as they are released today will work in combination with a existing release of Plone. I hope that's not true. It'd probably be true if ZTK packages have no regards for BBB with older versions of the library. If that's the case, you really should rename the packages in question, though. I once recall Jim saying the more I think about it, the more I think we can just never break backwards compatibility. That's the way it works in many other platforms, e.g. Java and .NET. And Python, maybe. Why do we have a urllib2? :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] dropping Python 2.4 support in the Zope Toolkit?
Martijn Faassen wrote: So I see two responses for Plone developers: * they know that they need new versions of zope.app.container and zope.app.component too and require people to upgrade those too. This might work fairly well, but does require the upgrade of more than just a *few* packages, with the increased risk of breakage. Or we can manage this with known good sets and careful testing. * they try to ignore this issue (because they don't know or care) and things may continue to work. Perhaps nobody ever uses Container in Plone anyway, and in practice everything's just fine. Based on a lot of luck. It's never going to be pretty, but it may be necessary given that the innovation that's going to happen further down the stack seems to move in an backwards-incompatible (or compatibility-challenge) direction. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Chris Withers wrote: plohn. ___ 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] Publishing buildout [versions] blocks for releases
Hi folks, I've written a small Google App Engine application to help manage and publish buildout configuration that provide a known good [versions] block. I'm not sure this approach is good, and the application is not well tested, but it may be of interest to some people here. http://good-py.appspot.com http://www.martinaspeli.net/articles/hello-good-py-a-known-good-versions-manager The code's in the collective, so I welcome improvements. I think it is at lest interesting using GAE for this type of thing, whether this particular application is the approach or not. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] dropping Python 2.4 support in the Zope Toolkit?
Martijn Faassen wrote: Hi there, What do people feel about dropping Python 2.4 support in the Zope Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave vaguely as we *still* don't have a canonical list) only have to work in Python 2.5 (and preferably 2.6), not Python 2.4 anymore. (this won't affect Zope 3.4 or below) One issue that came up recently was that .tgz releases to PyPI sometimes break with Python 2.4 due to a bug in Python 2.4. Using --zip is a workaround. And Plone currently depends on Python 2.4. Is it possible to work around this by *also* uploading a zip if we discover there's a problem with a package and it's pointed out there? If not, are there other workarounds? What do Zope 2 and Plone people in general think about moving to Python 2.5 for the newer releases? I'll note we're shuffling around the dependency structure so much in the Zope Toolkit it's unlikely everything will remain compatible for that reason as well. The Plone 3.x series will stay on Python 2.4 for a long time yet, so this would be very disappointing. I can understand it if the maintenance burden becomes large, or if there are compelling features of 2.5/2.6 that we really want to make use of. The tgz issue seems like a pretty weak reason, though, especially since there are workarounds. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues
Gary Poster wrote: I'm concerned about the state of the zc.buildout template recipes. I want one. I want some one-off files, specific to a certain project, for which writing a standalone recipe feels very heavy. Here are the template recipes I found: collective.recipe.template (Wichert Akkerman) FTR, this seems to be the de-facto choice in the Plone world, and it's quite well production-tested. I didn't even know about the others. :) z3c.recipe.template (Uli Fouquet) It's a bit disappointing that Uli created a new package rather than add the relatively minor feature missing from collective.recipe.template according to the PyPI page, although I agree the lack of tests is off-putting and should be fixed. Still, since the package was based on the other one, I don't see why we couldn't have added tests to collective.recipe.template rather than fork it. :-/ Since I don't find the prospect of creating yet another template recipe attractive, and Philipp's z3c.recipe.filetemplate looks like it can take my new features while maintaining backwards compatibility, I'll try that next, I suppose. What features do you want to add? Why can't they (plus the tests) go into the original collective.recipe.template? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues
Uli Fouquet wrote: In the beginning my code should go into collective.recipe.template itself (Wichert agreed), but I wasn't granted committer access to the collective repository yet. Of course I requested to be approval and waited for weeks, but nothing happened. I'm sorry to hear that! In general, access to the Collective is very unproblematic. Find an op in #plone on irc.freenode.net and they should be able to help you. How did you request the access? Clearly, something's broken down. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] dropping Python 2.4 support in the Zope Toolkit?
Andreas Jung wrote: What would be disappointing? To be unable to use new packages from an updated Zope Toolkit. It may be that some (many?) packages won't work with Zope 2.10, but if we get the kind of dependency isolation we're talking about, I'd wager that quite a few packages would work if pulled in independently. It's also generally silly to break compatibility with a platform if there's not a compelling reason to do so. I suspect there may be compelling reasons, but the TAR file issue isn't one of them. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] dropping Python 2.4 support in the Zope Toolkit?
Andreas Jung wrote: On 27.04.2009 17:07 Uhr, Martin Aspeli wrote: Andreas Jung wrote: What would be disappointing? To be unable to use new packages from an updated Zope Toolkit. It may be that some (many?) packages won't work with Zope 2.10, but if we get the kind of dependency isolation we're talking about, I'd wager that quite a few packages would work if pulled in independently. Would it be much work bringing Plone 3.X to Zope 2.12? It would be interesting to make it optional. I don't think we can make it required - too big a change for people using Plone 3.x and expecting forwards compatibility with new versions. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] dropping Python 2.4 support in the Zope Toolkit?
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Martin Aspeli wrote: The Plone 3.x series will stay on Python 2.4 for a long time yet, so this would be very disappointing. I can understand it if the maintenance burden becomes large, or if there are compelling features of 2.5/2.6 that we really want to make use of. The tgz issue seems like a pretty weak reason, though, especially since there are workarounds. Stability or goodies, pick one. If you can't upgrade to a newer Python / Zope, you can't use the ZTK, which *cannot* be constrained by backwared compatiblity with pre-2.12 Zope versions: those versions are stuck with using the Zope 3.3 / 3.4 trees on which they were originally based, just as they are stuck with Python 2.4. Thinking further on this: there is actually not much shiny about the ZTK: it is going to be equivalent to a cut-down, dependency-stripped, bbb-cruft-sanded version of the packages already shipping with Zope 2.10.x / 2.11.x. Until Plone quits using Zope2 altogether (likely never, AFAIK) Plone has no direct interest in the ZTK, which is just a layer of the Zope2 stack from Plone's perspective. In practice, though, people are using packages from newer Zope releases in third party products, and, possibly, in Plone core. One example is z3c.form, which requires you to upgrade zope.i18n and zope.component That works fine, FWIW. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] dropping Python 2.4 support in the Zope Toolkit?
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: Thinking further on this: there is actually not much shiny about the ZTK: it is going to be equivalent to a cut-down, dependency-stripped, bbb-cruft-sanded version of the packages already shipping with Zope 2.10.x / 2.11.x. Until Plone quits using Zope2 altogether (likely never, AFAIK) Plone has no direct interest in the ZTK, which is just a layer of the Zope2 stack from Plone's perspective. In practice, though, people are using packages from newer Zope releases in third party products, and, possibly, in Plone core. One example is z3c.form, which requires you to upgrade zope.i18n and zope.component That works fine, FWIW. :) But it won't be supported. Mix-and-match is not what the toolkit (or the related KGS / index stuff) is designed for. Sure. Which is why I said it would be disappointing (as opposed to negligent) if Python 2.4 support were dropped. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Laurence Rowe wrote: Martin Aspeli wrote: Hi, First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers. It kind of already does that if 'id' isn't set. But when 'id' is set, they diverge. Also note that according to ILocation, __name__ is a TextLine, which implies unicode. unicode ids are a no-no in Zope 2. The current solution I've put into dexterity is to let __name__ be a property that gets and sets id, but assumes its value is unicode. It'll fail if the unicode string can't be encoded to ASCII, though. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Hi, First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? Then, the proposal: In Zope 2.12, acquisition wrappers are optional. Instead of using a wrapper, acquisition can work by following __parent__ pointers. That work well for views, where these are now set properly, but no content currently maintains __parent__ pointers. We can fix this by introducing some code in OFS (and BTreeFolder2) that mimics what zope.container does. We can't use the setitem() and uncontained() helpers directly, since these deal with containment proxies and have slightly different semantics, but I think we can do this: 1) Add the following to _setOb: def _setOb(self, id, object): if ILocation.providedBy(object): if not IContained.providedBy(object): alsoProvides(object, IContained) oldname = getattr(object, '__name__', None) oldparent = getattr(object, '__parent__', None) if id is not oldname: object.__name__ = id if self is not oldparent: object.__parent__ = self setattr(self, id, object) 2) Add the following to _delOb: def _delOb(self, id): Remove the named object from the folder. try: obj = self._getOb(id, _marker) if obj is not _marker: if IContained.providedBy(obj): obj.__parent__ = None obj.__name__ = None except AttributeError: # No need to fail if we can't set these pass delattr(self, id) Note that there's a slight discrepancy here with the way zope.container works. In Zope 3, the __parent__ pointer is not unset until after the ObjectRemovedEvent is fired. In Zope 2, we only fire that event after the object has been fully removed (in _delObject()), but we have the ObjectWillBeRemovedEvent that is fired before. I don't think this really matters, though. 3) It'd be nice to also make ObjectManager and BTreeFolder2Base support the IContainer interface, so that OFS containers can be used with the more natural dict-like API of Zope 3 rather than the somewhat obscure getattr()/_getOb()/_setObject()-vs-_setOb() and so on API we have now. To add this, we'd just need to add a few methods to ObjectManager that calls the existing APIs, e.g. __getitem__, __delitem__, __setitem__ and so on. We have code for all three of these in plone.folder which could be pushed down to OFS an BTreeFolder2 quite easily. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Defining Zope 3.
Stephan Richter wrote: On Sunday 19 April 2009, Tres Seaver wrote: -1. As a branding choice (as opposed to a technology), Zope 3 *is* a dead-end: it implies a strategy (replacing Zope 2) which we no longer believe in. I think the consequences of the brand confusion are hard for those uf us inside to estimate, but they are far from trivial. I never communicated to anyone that I believe that Zope 3 is a successor of Zope 2. Other people pushed that message. It's not a message that needs pushing. In virtually every other piece of software ever created, when a version 3 comes out, it's meant to supersede version 2. No amount of navel-gazing is going to make that less confusing to people who are not happy to read the 40 messages of nuanced debate a day this list has produced lately. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Defining Zope 3.
Martijn Faassen wrote: Hey, Martin Aspeli wrote: [snip] I do realise that this derails Maritjn's focus slightly, but I don't think we've lost the idea that there may be value in maintaining a larger KGS. The whole idea of whatever-Zope 3-is-designated-as just being a larger KGS strikes me as strange. Frankly it strikes me as indicative of what's wrong with this community. Grok isn't just a KGS; it's a project and there's documentation and a web presence. Zope 2 isn't just a KGS either. Sigh... this discussion is just really difficult. I don't really understand what the problem is here, or why it's indicative of what's wrong with this community, but then I'm pretty lost in concepts and names at this stage. I think you're reading way too much into what I wrote though. I just meant thing using the Zope Toolkit but adding more stuff, e.g. an app server project or a shared management UI project. If the perception of such a thing is that limited... oh well, I will stop worrying about it altogether. It's not going to be very popular. I'll note again that the Zope Toolkit won't have documents on How to get started developing with the Zope Toolkit. True, though I hope it'll have some kind of documentation on how other projects can approach it and re-use it, or it won't be very successful. ;) I'll say again, though: Gary's version of the story (the Zope 3 community has become focused on supporting other app servers and frameworks, and is renaming the software stack that serves that purpose to the Zope Toolkit reads pretty well to me). Better than the other stories I've seen here, because it doesn't really concern itself with specific packages or features or a delta of those against a hypothetical smaller toolkit. In other words, I have a pretty good idea of what it means just from reading that sentence, and I can draw some conclusions about what it may mean for my existing Zope3-based projects and what it may mean for other projects (Grok, Zope 2, bfg) that have used Zope 3 components. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Defining Zope 3.
Martijn Faassen wrote: If we want to do this right we need to come up with a good way to get the message out. I think the only way you're going to manage to do that, is if you have a website with a clear and unambiguous message on it. It's like deja-vu all over again... Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Defining Zope 3.
Rob Miller wrote: Gary Poster wrote: This message seems like a reasonable start to me: Zope 3 has become focused on supporting frameworks and applications, rather than trying to be one itself. It is now called the Zope Toolkit. Parts of it are used by Zope 2, Plone, Grok, Repoze.bfg, and by many other different applications and frameworks. indeed, this seems to me a very nice message. short, pretty much accurate w/o delving too much into the mind-numbing details. yes, there may be some folks out there using the full Z3KGS as an app server, but those are the foks that already understand what's going on. they're just another community of people making good use of the Zope Toolkit. Trying to put myself in the shoes of an outsider, I agree with Rob in agreeing with Gary. This is a message that makes sense. I think, unfortunately, there's just too much confusion in names and meaning in the other threads here, which makes any decision based on those names and meanings very, very risky. I do realise that this derails Maritjn's focus slightly, but I don't think we've lost the idea that there may be value in maintaining a larger KGS. That shouldn't be called 'Zope 3' though, it should be called something else, or maybe a set of something elses, like the 'Zope Toolkit App Server Bundle' and the 'Zope Toolkit Management UI Bundle'. Or something. who knows, maybe the app-server-now-known-as-the-full-Z3KGS will grow in popularity to the point where it decides to rebrand itself as a groovy new platform. i'd recommend the name Zapp. ;) Heh, you always were good with names, Rob. ;-) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] SVN: Zope/trunk/ Let the permission / directive auto-register permissions that don't exist already
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Log message for revision 99146: Let the permission / directive auto-register permissions that don't exist already This kind of test is a poster child for why doctests with lots of output are fragile: even though it uses pprint, it *still* fails on different Python versions (i.e., it is breaking on Python 2.4). Sigh... sorry. I didn't even realise Zope 2.12 was meant to run with Python 2.4. I thought it was 2.5/2.6 only. Guess I was wrong. This test needs to be rewritten either as a traditional unittest (my preference), or the assertions about the state need to be rewritten in fine grained form. I just copied the tests that were already there, so I'd prefer to keep them in the same place. Can you show me the failure you get? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] who wants to maintain Zope 3?
Hanno Schlichting wrote: By now I count three people using Zope 3 for a small number of projects. But none of them seems to have the resources to continue the maintenance or future development of Zope 3. Whilst you're absolutely right, just a word of warning: a lot of people do not read mailing lists regularly or feel compelled to participate in them. This is the zope-dev list, which means that it's read primarily by Zope developers. If you're trying to gauge *users* of Zope 3, then the zope-user list may be a more appropriate place to ask, and even then, don't assume you'll get a representative sample of actual users. martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: Align Zope 2 and Zope 3 permissions
Martijn Faassen wrote: Hey, Martin Aspeli wrote: [snip] - In ZCML (or a grok.require() directive) use the Zope 3 name Grok also has a grok.Permission you can subclass, and those subclasses can also be passed to grok.require(). I know, but I kind of consider creating permissions by subclassing grok.Permission an anti-pattern. That is, I don't like the idea of using Python classes purely for declarative configuration. That's the kind of thing that ought to sit in a configuration file, IMHO, and ZCML works fine for that kind of thing. But I digress. ;) - In code, e.g. when doing a checkPermission() call, use the Zope 2 name - With GenericSetup's rolemap.xml, use the Zope 2 name We haven't gotten around to making grok.Permission subclasses useful here yet in Grok, but we should. [various proposal] Thoughts? I'm +1 on this, though with the caveat that I'm quite far from Zope 2 right now so I don't have a full picture of the impact. But it looks like a good way to move Zope 2 closer to the Zope Toolkit approach. Like I said, I think fixing it at the low level AccessControl API would be more invasive than I'd first thought. I'm not sure it's a safe thing to attempt right now... Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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/ Make the set_attributes and set_schema options to class ...require ... //class issue a warning rather than throw an exception. Whilst the concept doesn't make mu
Log message for revision 99145:
Make the set_attributes and set_schema options to class ...require ...
//class issue a warning rather than throw an exception. Whilst the concept
doesn't make much sense in Zope 2, it's desirable to be able to re-use existing
packages that do declare such protection
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/Products/Five/metaconfigure.py
U Zope/trunk/src/Products/Five/tests/test_security.py
-=-
Modified: Zope/trunk/doc/CHANGES.rst
===
--- Zope/trunk/doc/CHANGES.rst 2009-04-13 02:25:29 UTC (rev 99144)
+++ Zope/trunk/doc/CHANGES.rst 2009-04-13 10:15:12 UTC (rev 99145)
@@ -23,6 +23,11 @@
Restructuring
+
+- Using require set_schema=... / or require set_attributes=... / in
+ the class / directive now emits a warning rather than an error. The
+ concept of protecting attribute 'set' does not exist in Zope 2, but it
+ should be possible to re-use packages that do declare such protection.
+
- Updated to DateTime 2.12.0.
- Updated to ZODB 3.9.0a12.
Modified: Zope/trunk/src/Products/Five/metaconfigure.py
===
--- Zope/trunk/src/Products/Five/metaconfigure.py 2009-04-13 02:25:29 UTC
(rev 99144)
+++ Zope/trunk/src/Products/Five/metaconfigure.py 2009-04-13 10:15:12 UTC
(rev 99145)
@@ -16,12 +16,11 @@
$Id$
import warnings
-from zope.configuration.exceptions import ConfigurationError
-from zope.app.component import contentdirective
+from zope.security import metaconfigure
from App.class_init import InitializeClass
from Products.Five.security import protectName
-class ClassDirective(contentdirective.ClassDirective):
+class ClassDirective(metaconfigure.ClassDirective):
def __protectName(self, name, permission_id):
self.__context.action(
@@ -30,14 +29,17 @@
args = (self.__class, name, permission_id)
)
-def __protectSetAttributes(self, attributes, permissions):
-raise ConfigurationError('set_attributes parameter not supported.')
+def __protectSetAttributes(self, names, permission_id):
+warnings.warn(The set_attribute option of the require / directive
is not supported in Zope 2. + \
+ Ignored for %s % str(self.__class), stacklevel=3)
-def __proctectSetSchema(self, schema, permission):
-raise ConfigurationError('set_schema parameter not supported.')
+def __protectSetSchema(self, schema, permission):
+warnings.warn(The set_schema option of the require / directive is
not supported in Zope 2. + \
+ Ignored for %s % str(self.__class), stacklevel=3)
def __mimic(self, _context, class_):
-raise ConfigurationError('like_class parameter not supported.')
+warnings.warn(The like_class option of the require / directive is
not supported in Zope 2. + \
+ Ignored for %s % str(self.__class), stacklevel=3)
def __call__(self):
return self.__context.action(
Modified: Zope/trunk/src/Products/Five/tests/test_security.py
===
--- Zope/trunk/src/Products/Five/tests/test_security.py 2009-04-13 02:25:29 UTC
(rev 99144)
+++ Zope/trunk/src/Products/Five/tests/test_security.py 2009-04-13 10:15:12 UTC
(rev 99145)
@@ -18,6 +18,7 @@
from zope.interface import implements
from zope.interface import Interface
+from zope.schema import TextLine
from AccessControl.SecurityInfo import ClassSecurityInfo
class ISuperDummy(Interface):
@@ -51,6 +52,16 @@
security.declarePrivate('baz')
security.declareProtected('View management screens', 'keg')
+class IDummy3(Interface):
+attr = TextLine(title=uAttribute)
+
+class Dummy3:
+implements(IDummy3)
+attr = None
+
+class Dummy4:
+foo = None
+
def test_security_equivalence():
This test demonstrates that the traditional declarative security of
Zope 2 can be replaced by ZCML statements without any loss of
@@ -219,6 +230,56 @@
tearDown()
+def test_set_warnings():
+This test demonstrates that set_attributes and set_schema will result
+in warnings, not errors. This type of protection doesn't make sense in
+Zope 2, but we want to be able to re-use pure Zope 3 packages that use
+them without error.
+
+ from zope.app.testing.placelesssetup import setUp, tearDown
+ setUp()
+
+Before we can make security declarations through ZCML, we need to
+register the directive and the permission:
+
+ import Products.Five
+ from Products.Five import zcml
+ zcml.load_config('meta.zcml', Products.Five)
+ zcml.load_config('permissions.zcml', Products.Five)
+
+Now we provide some ZCML declarations for ``Dummy1``:
+
+ configure_zcml = '''
+ ... configure xmlns=http://namespaces.zope.org/zope;
+ ...
+ ... class
[Zope-Checkins] SVN: Zope/trunk/ Let the permission / directive auto-register permissions that don't exist already
Log message for revision 99146:
Let the permission / directive auto-register permissions that don't exist
already
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/Products/Five/permissions.zcml
U Zope/trunk/src/Products/Five/security.py
U Zope/trunk/src/Products/Five/tests/test_security.py
-=-
Modified: Zope/trunk/doc/CHANGES.rst
===
--- Zope/trunk/doc/CHANGES.rst 2009-04-13 10:15:12 UTC (rev 99145)
+++ Zope/trunk/doc/CHANGES.rst 2009-04-13 10:46:06 UTC (rev 99146)
@@ -23,6 +23,12 @@
Restructuring
+
+- If the permission / ZCML directive is used to declare a permission that
+ does not exist, the permission will now be created automatically, defaulting
+ to being granted to the Manager role only. This means it is possible to
+ create new permissions using ZCML only. The permission will Permissions that
+ already exist will not be changed.
+
- Using require set_schema=... / or require set_attributes=... / in
the class / directive now emits a warning rather than an error. The
concept of protecting attribute 'set' does not exist in Zope 2, but it
Modified: Zope/trunk/src/Products/Five/permissions.zcml
===
--- Zope/trunk/src/Products/Five/permissions.zcml 2009-04-13 10:15:12 UTC
(rev 99145)
+++ Zope/trunk/src/Products/Five/permissions.zcml 2009-04-13 10:46:06 UTC
(rev 99146)
@@ -1,6 +1,13 @@
configure xmlns=http://namespaces.zope.org/zope;
i18n_domain=Five
+ !-- Create permissions declared in ZCML if they don't exist already --
+ subscriber
+for=zope.security.interfaces.IPermission
+ zope.component.interfaces.IRegistered
+handler=.security.create_permission_from_permission_directive
+/
+
permission
id=five.ManageSite
title=Manage Five local sites
Modified: Zope/trunk/src/Products/Five/security.py
===
--- Zope/trunk/src/Products/Five/security.py2009-04-13 10:15:12 UTC (rev
99145)
+++ Zope/trunk/src/Products/Five/security.py2009-04-13 10:46:06 UTC (rev
99146)
@@ -34,7 +34,13 @@
from AccessControl.SecurityInfo import ClassSecurityInfo
from AccessControl.SecurityManagement import getSecurityManager
+from AccessControl.Permission import _registeredPermissions
+from AccessControl.Permission import pname
+import Products
+
+from Globals import ApplicationDefaultPermissions
+
CheckerPublicId = 'zope.Public'
CheckerPrivateId = 'zope2.Private'
@@ -155,3 +161,21 @@
# Zope 2 uses string, not unicode yet
perm = str(permission.title)
security.declareObjectProtected(perm)
+
+def create_permission_from_permission_directive(permission, event):
+When a new IPermission utility is registered (via the permission /
+directive), create the equivalent Zope2 style permission.
+
+
+global _registeredPermissions
+
+zope2_permission = permission.title
+roles = ('Manager',)
+
+if not _registeredPermissions.has_key(zope2_permission):
+_registeredPermissions[zope2_permission] = 1
+
+Products.__ac_permissions__ += ((zope2_permission, (), roles,),)
+
+mangled = pname(zope2_permission)
+setattr(ApplicationDefaultPermissions, mangled, roles)
Modified: Zope/trunk/src/Products/Five/tests/test_security.py
===
--- Zope/trunk/src/Products/Five/tests/test_security.py 2009-04-13 10:15:12 UTC
(rev 99145)
+++ Zope/trunk/src/Products/Five/tests/test_security.py 2009-04-13 10:46:06 UTC
(rev 99146)
@@ -374,6 +374,76 @@
tearDown()
+def test_register_permission():
+This test demonstrates that if the permission / directive is used
+to create a permission that does not already exist, it is created on
+startup, with roles defaulting to Manager.
+
+ from zope.app.testing.placelesssetup import setUp, tearDown
+ setUp()
+
+First, we need to configure the relevant parts of Five.
+
+ import Products.Five
+ from Products.Five import zcml
+ zcml.load_config('meta.zcml', Products.Five)
+ zcml.load_config('permissions.zcml', Products.Five)
+
+We can now register a permission in ZCML:
+
+ configure_zcml = '''
+ ... configure xmlns=http://namespaces.zope.org/zope;
+ ...
+ ... permission
+ ... id=Products.Five.tests.DummyPermission
+ ... title=Five: Dummy permission
+ ... /
+ ...
+ ... /configure
+ ... '''
+ zcml.load_string(configure_zcml)
+
+The permission will be made available globally, with default role set
+of ('Manager',).
+
+ from pprint import pprint
+ pprint(self.app.rolesOfPermission('Five: Dummy permission'))
+ [{'name': 'Anonymous', 'selected': ''},
+
Re: [Zope-dev] Proposal: Align Zope 2 and Zope 3 permissions
Dieter Maurer wrote: Martin Aspeli wrote at 2009-4-12 18:31 +0800: Finally, there is not total parity between Zope 2 security and Zope 3 security. Zope 2 cannot protect 'property set', for example. Since Zope 2.8, Zope 2 could in principle -- and until quite recently I thought, it really can: it only fails with the context check (is the accessed object in the context of the UserFolder authenticating the current user). Of course, such checks fail for objects not acquisition wrapped. If we let pass this check in such cases, Zope 2 can protect property sets. Not sure I understand you here. How would I declare that 'set' of an attribute (property) is protected by one permission and 'get' is protected by another? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: Align Zope 2 and Zope 3 permissions
Martin Aspeli wrote: I've now implemented 1 and 2 on trunk, since they seem pretty non-controversial. 1) Use an event handler to ensure that any permission / declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease. and 2) Emit a warning instead of an error in Five's handler for the class / directive when set_attributes or set_schema are used. I've not done this yet: 3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly. I'd like to solicit a bit more input before attempting this, as I got at least one -1. I think this is the bigger win, though, and I'd still like to do it unless performance becomes prohibitive or it turns out to be too invasive a change. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] who wants to maintain Zope 3?
Hermann Himmelbauer wrote: -1 from my standpoint. Two of my projects are fully based on the Zope 3 server, and switching to something else would be quite some pain. FWIW, I think you're absolutely right. We can't just declare it dead because it is convenient to our goal of having clearer definitions about what we're working with. A piece of open source software is dead if no-one uses it and no-one maintains it. At least then, existing users can't count on bug fixers or security fixes. I think Martijn's point in starting this thread was to try to identify who wants to maintain Zope 3 as an app server and as something that gets released going forward. Let's give those people a chance to respond. Declaring things dead has a tendency to become a self-fulfilling prophecy, and probably not something we should do lightly. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: Align Zope 2 and Zope 3 permissions
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: I've not done this yet: 3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly. I'd like to solicit a bit more input before attempting this, as I got at least one -1. I think this is the bigger win, though, and I'd still like to do it unless performance becomes prohibitive or it turns out to be too invasive a change. - -1: I think both of those will be true. I also don't see much win. The major goal should be to unify the API for add-ons, rather than the implementation: your #1 and #2 alaready did that, I think. I had a deeper look last night, and I think this would be more invasive than I'd feared. I thought originally the Permission class was used everywhere, but on further inspection, I see that manually constructed '_Permission' strings are used in a lot of places, including C code. It frightens me slightly that, having pdb'd my way through AccessControl a number of times, I still have only a fuzzy idea about how the permissions system works, and I haven't found any solid documentation with the code. I think to unify the API, we'd need to: - Promote the zope.security checkPermission method like Hanno suggested - Change rolemap.xml in GenericSetup to accept Zope 2 names - Look at other places where permission names are passed around in code (there are a few places in Plone, for instance) and make sure we always prefer the Zope 3 dotted name. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: Align Zope 2 and Zope 3 permissions
Hi all, For a while now, people have had to contend with two ways of doing certain things, depending on whether the code they are working with is in Zope 2 land or Zope 3 land. We're getting closer to a world where people don't need to be so intimately aware of the differences, especially since the __parent__ pointer work was merged, and some of the unification of page templates. However, we still have to do a lot of explaining in the realm of permissions. Five installs a Zope 3 security checker that checks against Zope 2 security. It does so by treating the title of a Zope 3 style IPermission utility as a Zope 2 permission string. This works well, and has allowed us to create valid Zope 3 permissions for the core Zope 2 and CMF permissions (e.g. zope2.View, cmf.ModifyPortalContent) for use in views and the like. However, it's not clear to new users where to use the Zope 3 style dotted name and where to use the Zope 2 permission string. As a rule of thumb, the rules are something like: - In ZCML (or a grok.require() directive) use the Zope 3 name - In code, e.g. when doing a checkPermission() call, use the Zope 2 name - With GenericSetup's rolemap.xml, use the Zope 2 name The waters are muddied further by components that require a permission to be listed or provided explicitly. Some use the Zope 2 name, some use the Zope 3 name. The other problem is that a permission / ZCML directive does not actually register a Zope 2 style permission, it merely maps an existing permission to a new name. Since Zope 2 permissions spring into existence in difficult-to-explain ways, that causes a lot of confusion. Finally, there is not total parity between Zope 2 security and Zope 3 security. Zope 2 cannot protect 'property set', for example. To this end, Five throws exceptions if you use a ZCML class / directive with set_attributes or or set_schema. Whilst this makes sense, it makes it harder to re-use existing packages that do have that kind of protection in place. Since the concept does not exist in Zope 2, I think it makes sense to ignore this with a warning, rather than error. So, here is what I'd like to propose, ideally for Zope 2.12: 1) Use an event handler to ensure that any permission / declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease. http://dev.plone.org/collective/browser/collective.autopermission/trunk/collective/autopermission/permissions.py Benefits: Creating new permissions becomes more predictable. Risks: None obvious. The event handler will not override permissions that already exist. 2) Emit a warning instead of an error in Five's handler for the class / directive when set_attributes or set_schema are used. Benefits: Easier to re-use existing packages Risks: The attributes won't actually be protected. However, since Zope 2 doesn't have the concept of protecting 'set' (or security proxies) then I'm not sure there's a problem of expectation. 3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly. Benefits: Should transparently allow any invocation of the Zope 2 API to use Zope 3 permission names, allowing us to document that the dotted permission name is the canonical name everywhere. Risks: Performance overhead of doing utility lookups. May result in name clashes, but since the permission name is a dotted name and the Zope 2 permission name isn't, I think it's extremely unlikely that this would actually happen in practice. Thoughts? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] z3c.form and KGS 3.4 - can't build 1.9.x branch
Stephan Richter wrote: On Thursday 09 April 2009, Martin Aspeli wrote: Clearly, I'm getting too new a version of RestrictedPython, but this is running against the 3.4 KGS, so I don't see how that could really happen. This is not a problem. Ignore those errors as they happen in the Python 2.6 support code.Everything installed fine. Got RestrictedPython 3.5.0. Mmm... it doesn't let me run the tests though: $ ./bin/test Test-module import failures: Module: z3c.form.browser.tests Traceback (most recent call last): File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/browser/tests.py, line 16, in ? from z3c.form import testing File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/testing.py, line 28, in ? from zope.app.testing import setup File /Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg/zope/app/testing/setup.py, line 47, in ? from zope.container.traversal import ContainerTraversable File /Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/traversal.py, line 26, in ? from zope.publisher.interfaces import IDefaultViewName, NotFound ImportError: cannot import name IDefaultViewName Module: z3c.form.tests.test_doc Traceback (most recent call last): File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/test_doc.py, line 23, in ? from zope.app.testing import placelesssetup File /Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg/zope/app/testing/placelesssetup.py, line 26, in ? from zope.container.testing \ File /Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/testing.py, line 29, in ? from zope.container.traversal import ContainerTraversable File /Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/traversal.py, line 26, in ? from zope.publisher.interfaces import IDefaultViewName, NotFound ImportError: cannot import name IDefaultViewName Test-modules with import problems: z3c.form.browser.tests z3c.form.tests.test_doc Total: 0 tests, 0 failures, 0 errors in 0.000 seconds. (optilude)(~/Development/Plone/Code/Products/z3c.form) $ My working set is pretty weird too. Lots of 3.5.x and 3.6.x and even a 3.8.x. $ cat bin/test #!/opt/local/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python import sys sys.path[0:0] = [ '/users/optilude/Development/Plone/Code/Products/z3c.form/src', '/Users/optilude/.buildout/eggs/zope.testing-3.7.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.interface-3.5.0-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/setuptools-0.6c9-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.i18n-3.4.4-py2.4.egg', '/Users/optilude/.buildout/eggs/z3c.template-1.1a1-py2.4.egg', '/Users/optilude/.buildout/eggs/z3c.coverage-0.1.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.container-3.7.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.security-3.6.0-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.schema-3.5.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.publisher-3.5.5-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.pagetemplate-3.4.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.location-3.5.3-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.lifecycleevent-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.i18nmessageid-3.4.3-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.i18n-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.event-3.4.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.configuration-3.4.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.component-3.5.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.pagetemplate-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/ZODB3-3.9.0a12-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.app.publisher-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.component-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.tal-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.copypastemove-3.5.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.dublincore-3.4.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.traversing-3.5.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.size-3.4.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.exceptions-3.5.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.proxy-3.5.0-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.deferredimport-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/pytz-2009a-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.deprecation-3.4.0-py2.4.egg
Re: [Zope-dev] z3c.form and KGS 3.4 - can't build 1.9.x branch
Adam GROSZER wrote: Hello, I would add TEMPORARYLY (for testing) the KGS to buildout.cfg: [buildout] extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg versions = versions develop = . benchmark parts = test checker coverage-test coverage-report docs i18n benchmark python ... But do not commit that! I think people will use KGS in their buildout if they want and that will nail versions appropriately. Later we might backport the [3.5/trunk]-compatibility which I'd like to finish this weekend to 1.9. The tests now fail with: $ ./bin/test Running unit tests: Failure in test /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt Failed doctest test for zcml.txt File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt, line 0 -- File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt, line 67, in zcml.txt Failed example: from z3c.template.interfaces import IPageTemplate Exception raised: Traceback (most recent call last): File /Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py, line 1356, in __run compileflags, 1) in test.globs File doctest zcml.txt[19], line 1, in ? from z3c.template.interfaces import IPageTemplate ImportError: No module named template.interfaces -- File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt, line 68, in zcml.txt Failed example: template = zope.component.queryMultiAdapter((None, request, None, None, myWidget), interface=IPageTemplate, name='input') Exception raised: Traceback (most recent call last): File /Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py, line 1356, in __run compileflags, 1) in test.globs File doctest zcml.txt[20], line 2, in ? myWidget), interface=IPageTemplate, name='input') NameError: name 'IPageTemplate' is not defined -- File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt, line 73, in zcml.txt Failed example: template Exception raised: Traceback (most recent call last): File /Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py, line 1356, in __run compileflags, 1) in test.globs File doctest zcml.txt[21], line 1, in ? template NameError: name 'template' is not defined -- File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt, line 78, in zcml.txt Failed example: print template(myWidget) Exception raised: Traceback (most recent call last): File /Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py, line 1356, in __run compileflags, 1) in test.globs File doctest zcml.txt[22], line 1, in ? print template(myWidget) NameError: name 'template' is not defined Ran 740 tests with 1 failures and 0 errors in 4.211 seconds. (optilude)(~/Development/Plone/Code/Products/z3c.form) I don't really feel confident to fix bugs in z3c.form until I can have a stable build environment, but I may check in some fixes anyway if I find time this weekend and aim to keep the number of failures constant. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] naming Zope
Wichert Akkerman wrote: Previously Shane Hathaway wrote: discussion type=bikeshed Tres Seaver wrote: WRT the Framework name: framework is a misleading name for the collection of packages salvaged from the new Coke effort: it is actually a *bunch* of frameworks, in the classic software engineering sense, along with some pure libraries. Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] ) +1 Cute. It can even be shortened to ZTool. Then we need a package ztool.sample. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] naming Zope
Wichert Akkerman wrote: Previously Martin Aspeli wrote: Wichert Akkerman wrote: To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump. -100 again. We need to stop confusing people! The only way we could do this would be if we definitely, 100%, with-an-axe killed off any notion of Zope 3 as an app server or application development framework and told everyone the thing you need to be using if you like Zope, is this Zope thing that's basically Zope 2.14). We won't do that. Actually, we have already done that. Well, except that Grok runs on Zope 3 the app server or at least Zope 3 the platform. I just think we need to stop playing with names and numbers. I have absolutely no problem with Zope 2 version numbers reaching 2.20 or whatever. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] z3c.form and KGS 3.4 - can't build 1.9.x branch
Hi, I just tried to check out the new 1.9.x branch of z3c.form (thanks Stephan!), but it won't build with Python 2.4 (I need this to work with Plone, so 2.4 is a must): $ ./bin/buildout Develop: '/users/optilude/Development/Plone/Code/Products/z3c.form/.' Unused options for buildout: 'zope-directory' 'download-directory'. Installing test. Getting distribution for 'z3c.template'. Got z3c.template 1.1a1. Getting distribution for 'z3c.coverage'. Got z3c.coverage 0.1.0. Getting distribution for 'zope.app.container'. Got zope.app.container 3.7.0. Getting distribution for 'zope.security'. Got zope.security 3.6.0. Getting distribution for 'zope.publisher'. Got zope.publisher 3.5.5. Getting distribution for 'zope.pagetemplate'. Got zope.pagetemplate 3.4.1. Getting distribution for 'zope.lifecycleevent'. Got zope.lifecycleevent 3.5.0. Getting distribution for 'zope.configuration'. Got zope.configuration 3.4.1. Getting distribution for 'zope.app.testing'. Got zope.app.testing 3.6.0. Getting distribution for 'zope.app.pagetemplate'. Got zope.app.pagetemplate 3.5.0. Getting distribution for 'ZODB3'. Got ZODB3 3.9.0a12. Getting distribution for 'zope.app.publisher'. Got zope.app.publisher 3.6.0. Getting distribution for 'zope.app.component'. Got zope.app.component 3.6.0. Getting distribution for 'zope.tal'. Got zope.tal 3.5.0. Getting distribution for 'zope.dublincore'. Got zope.dublincore 3.4.2. Getting distribution for 'zope.traversing'. Got zope.traversing 3.5.2. Getting distribution for 'zope.proxy=3.4.2'. Got zope.proxy 3.5.0. Getting distribution for 'zope.deferredimport'. Got zope.deferredimport 3.5.0. Getting distribution for 'zope.app.security'. Got zope.app.security 3.6.0. Getting distribution for 'zope.app.publication'. Got zope.app.publication 3.5.1. Getting distribution for 'zope.app.authentication'. Got zope.app.authentication 3.5.0a2. Getting distribution for 'zope.app.appsetup=3.5.0'. Got zope.app.appsetup 3.9.0. Getting distribution for 'zope.contenttype'. Got zope.contenttype 3.4.1. Getting distribution for 'zope.formlib'. Got zope.formlib 3.5.2. Getting distribution for 'zope.filerepresentation'. Got zope.filerepresentation 3.5.0. Getting distribution for 'zope.dottedname'. Got zope.dottedname 3.4.5. Getting distribution for 'zope.app.form'. Got zope.app.form 3.7.1. Getting distribution for 'zope.app.exception'. Got zope.app.exception 3.4.2. Getting distribution for 'zope.app.http'. Got zope.app.http 3.5.0. Getting distribution for 'zope.error'. Got zope.error 3.6.0. Getting distribution for 'zope.session'. Got zope.session 3.8.0. Getting distribution for 'RestrictedPython'. File build/bdist.macosx-10.3-i386/egg/RestrictedPython/tests/before_and_after25.py, line 30 x.y = y.z if y.z else y.x ^ SyntaxError: invalid syntax File build/bdist.macosx-10.3-i386/egg/RestrictedPython/tests/before_and_after26.py, line 30 with whatever as x: ^ SyntaxError: invalid syntax File build/bdist.macosx-10.3-i386/egg/RestrictedPython/tests/security_in_syntax26.py, line 6 with x as _leading_underscore: ^ SyntaxError: invalid syntax File /Users/optilude/.buildout/eggs/tmpayO5gI/RestrictedPython-3.5.0-py2.4.egg/RestrictedPython/tests/before_and_after25.py, line 30 x.y = y.z if y.z else y.x ^ SyntaxError: invalid syntax File /Users/optilude/.buildout/eggs/tmpayO5gI/RestrictedPython-3.5.0-py2.4.egg/RestrictedPython/tests/before_and_after26.py, line 30 with whatever as x: ^ SyntaxError: invalid syntax File /Users/optilude/.buildout/eggs/tmpayO5gI/RestrictedPython-3.5.0-py2.4.egg/RestrictedPython/tests/security_in_syntax26.py, line 6 with x as _leading_underscore: ^ SyntaxError: invalid syntax Got RestrictedPython 3.5.0. Generated script '/users/optilude/Development/Plone/Code/Products/z3c.form/bin/test'. Installing coverage-test. Generated script '/users/optilude/Development/Plone/Code/Products/z3c.form/bin/coverage-test'. Installing coverage-report. Couldn't find index page for 'z3c.coverage' (maybe misspelled?) Generated script '/users/optilude/Development/Plone/Code/Products/z3c.form/bin/coverage-report'. Clearly, I'm getting too new a version of RestrictedPython, but this is running against the 3.4 KGS, so I don't see how that could really happen. :( Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] naming Zope
Martijn Faassen wrote: Let's talk about Zope Classic and see whether renaming Zope 2 to that is a step we can realistically take in the near future. Who is in favor of that? -100 Zope 2 is an incredibly established name. It's been around forever. Renaming something that has been out there for years and years and is mentioned in thousands of pages of documentation (including books) is a recipe for confusion. To the outside world, this will sound like renaming for renaming's sake. If you look at the companies that have done this with their brand names, it's normally a disaster and costs a fortune in marketing to set the record straight in people's minds. Don't believe for a moment that the common usage in the chatter in cyberspace and real life is going to change over night (or even over a few weeks or months) just because it is suddenly decreed. It'll be a point of confusion we'll have to deal with for years. Also, if Zope Framework is the set of re-usable libraries and Zope 3 is what remains after factoring out this, then the terms Zope 2 and Zope 3 are probably closer in representation to their original goal. Whether Zope 3 is *successful* in succeeding Zope 2 is another matter. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] naming Zope
Martijn Faassen wrote: Hey, Okay, in the interests of making this discussion go quickly, there has been enough negative feedback about renaming Zope 2 to think we have no realistic chance of renaming it. We are still stuck with the following perceived sequence: Zope 2, Zope 3 which implies that people should want to upgrade. Does it? There's precedence for systems where n and n+1 does not represent a linear upgrade path. The '3' says more if you're starting afresh, this is where you want to start. I think that's still a correct statement. If we don't call Zope Framework 4.0, we'll be fine. We should call its first release 1.0 and there's no implication of a progression. Yes. For the love of God, please don't call the Zope Framework 4.0! Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] naming Zope
Wichert Akkerman wrote: To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump. -100 again. We need to stop confusing people! The only way we could do this would be if we definitely, 100%, with-an-axe killed off any notion of Zope 3 as an app server or application development framework and told everyone the thing you need to be using if you like Zope, is this Zope thing that's basically Zope 2.14). We won't do that. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] z3c.form - status of 1.9.0 and 2.0 (and a bug)
Hi, Today, I found a bug in ChoiceTerms: it will only bind the field if field.vocabulary is None, which breaks uses of an IContextSourceBinder. I thought to fix that in svn, but there's no 1.9.x branch, and 2.0 (trunk) is a very different beast. Tracking 2.0 trunk is not an option right now. I couldn't even get Zope to start up with 2.0 trunk, which is depending on lots of 3.5.x packages that I can't get to work with Zope. So, for now, I've made do with a monkey patch, but that's obviously not ideal. So: - When will we see a 2.0 release? I asked that question months ago, but I'm not sure if we're any closer? - What do we do with the 1.9.x line? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Constant values defined in interfaces
Chris Rossi wrote:
from zope.interface import Constant
class IHttpResponse(Interface):
Models an HTTP 1.1 response.
HTTP_OK = Constant(200 Ok, An HTTP Ok response.)
HTTP_NOT_FOUND = Constant(404 Not Found, An HTTP Not Found response)
status = Attribute(HTTP status code for this response.)
Using descriptors, the results could be both static and immutable.
Does this seem useful to anyone besides me? Anyone who's done much Java
programming will recognize that I did not have an original idea here.
-1
I think having a more robust way to spell and namespace constants may be
interesting, but what we see above, with a mixed interface/class, is
actually not going to work given zope.interface's semantics. You'd end
up with an interface that promised an attribute that didn't exist.
In Java, you can do:
interface IFoo {
public static String FOO = foo;
}
class Foo implements IFoo {}
f = Foo();
System.out.println(f.FOO);
In Python with zope.interface, implements() doesn't mean you inherit
attributes. Therefore, you'd need to do:
class IFoo(Interface):
FOO = Constant(foo)
class Foo(object):
implements(IFoo)
FOO = foo # or FOO = IFoo['FOO'].get() or something
f = Foo()
print f.FOO
Without repeating the definition of the FOO constant in each class
implementing IFoo, the interface would be promising an attribute that
didn't exist. validateInterface() would complain too.
In general, I don't have a problem with doing constants that are not,
strictly speaking, immutable. I tend to put them in interfaces.py if
they are part of the contract of my package. Codifying that as good
practice is probably a good idea. We certainly could come up with some
other way of spelling this, e.g.
class FooConstants(Constants):
FOO = Contant(Foo)
or whatever... maybe some way to mix in zope.schema to to describe the
fields in more details. But it feels like a fair amount of situps when
you can just do FOO = Foo at module level and be done with it. Python
is a dynamic language. We don't have privates or final methods or lots
of other things that you can spell in a strictly typed, compiled
language like Java.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
Zope-Dev maillist - Zope-Dev@zope.org
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] Announcing: Zope 4.0 project
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Zope community, I am pleased to announce the creation of the Zope 4.0 project. After extensive discussion with the Zope wizards in conclave at PyCon 2009, the new project's website has been launched: http://zopefour.org/ Ah, best one yet. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Two small convenience suggestions for zope.interface and zope.component
Hi, I'd like to add support for the following: 1) Provider decorator: @provider(IFoo) def some_function(context) pass This is an alternative to doing a separate alsoProvides() on the function. 2) An interfaceProvides directive: class IFoo(Interface): interfaceProvides(ISomeMarker) This is alternative to doing alsoProvides() on the interface. The reason for this is that currently, you have to put those alsoProvides() lines after the function or interface. This makes them difficult to find if the bodies of the functions or interfaces are long, and goes against the convention of having the what is this information at the top of the entity. I can probably help implement this. Any thoughts? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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 for ZCML
Stephan Richter wrote: On Tuesday 17 March 2009, Martijn Faassen wrote: If a package defines a *lot* of ZCML, we will have to wonder about the purpose of the package (is this really a library-like package or more like an application defining a UI or something?), and we'll have to think about another strategy. I want to move this discussion to concrete examples next and see what a treatment of moving out ZCML would entail. A common complaint I am hearing about z3c.form, for example, is that I should use the ZCML more in my doctests, so that the doctests contain more example on how to use ZCML to create z3c.form pages. At work I have started taking this approach more and more and it makes tests actually more readable and provides better documentation to consumers of the libraries/code. I have had the same realisation. One possible compromise if you don't want to actually use the XML configuration language, is to show an example ZCML file, but to actually register with the zope.component API. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] distribution broken
Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.03.2009 1:17 Uhr, Martin Aspeli wrote: Andreas Jung wrote: As mentioned earlier: use buildout. easy_install support has no high priority right now. Whilst I understand that we don't have the capacity to test all different configurations now, I think it's a good principle to try to avoid a 'hard' dependency on zc.buildout. If we can, we should rely on e.g. setuptools console scripts rather than things generated through specific recipes. Of course, this is just part of an evolution. 'mkzopeinstance' was a completely custom build solution. Using a standard zc.buildout configuration is better, imho, than maintaining a custom build script. But using just setuptools/eggs and letting buildout be a preference rather than a hard dependency is better still. hmm.? The easy_install approach was working at the time when we released a1 some weeks ago. So there must be a small problem causing the issue. In fact easy_install Zope2 acts like configure; make and will create bin/mkzopeinstance and all the other stuff within out Python environment. We will also check about having the traditional source-dist containing everything..but we are at alpha 1 right now. That's excellent - I didn't know that we were so far along. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] zc.relationship - can't pickle module objects
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2. In
particular, it subclasses zc.relationship.shared.Container, and stores
a zc.relationship.index.Index object in self.relationIndex.
Now, the __init__ of zc.relationship.index.Index, which derives from
Persistent, contains the code below. In self._relTools and and
self._attrs, there are a pile of modules, types and functions being
stored. I think these are causing the ZODB to barf. Interestingly, with
whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no
problem.
Any ideas how to work around this, or even why it's a problem in one
version of the ZODB but not another?
zc.relationship.index.Index's initialiser:
def __init__(self, attrs, defaultTransitiveQueriesFactory=None,
dumpRel=generateToken, loadRel=resolveToken,
relFamily=IFBTree, deactivateSets=False):
self._name_TO_mapping = OOBTree.OOBTree()
# held mappings are objtoken to (relcount, relset)
self._EMPTY_name_TO_relcount_relset = OOBTree.OOBTree()
self._reltoken_name_TO_objtokenset = OOBTree.OOBTree()
self.defaultTransitiveQueriesFactory =
defaultTransitiveQueriesFactory
self._relTools = getModuleTools(relFamily)
self._relTools['load'] = loadRel
self._relTools['dump'] = dumpRel
self._relLength = Length.Length()
self._relTokens = self._relTools['TreeSet']()
self.deactivateSets = deactivateSets
self._attrs = _attrs = {} # this is private, and it's not
expected to
# mutate after this initial setting.
seen = set()
for data in attrs:
# see README.txt for description of attrs.
if zope.interface.interfaces.IElement.providedBy(data):
data = {'element': data}
res = getModuleTools(data.get('btree', IFBTree))
res['element'] = val = data['element']
res['attrname'] = val.__name__
res['name'] = data.get('name', res['attrname'])
if res['name'] in _attrs or val in seen:
raise ValueError('Duplicate in attrs', name, val)
seen.add(val)
_attrs[res['name']] = res
res['dump'] = data.get('dump', generateToken)
res['load'] = data.get('load', resolveToken)
if (res['dump'] is None) ^ (res['load'] is None):
raise ValueError(
either both of 'dump' and 'load' must be None, or
neither)
# when both load and dump are None, this is a small
# optimization that can be a large optimization if the
returned
# value is one of the main four options of the selected
btree
# family (BTree, TreeSet, Set, Bucket).
res['interface'] = val.interface
res['multiple'] = data.get('multiple', False)
res['call'] = zope.interface.interfaces.IMethod.providedBy(val)
if res['TreeSet'].__name__.startswith('I'):
Mapping = IOBTree.IOBTree
else:
assert res['TreeSet'].__name__.startswith('O')
Mapping = OOBTree.OOBTree
self._name_TO_mapping[res['name']] = Mapping()
# these are objtoken to (relcount, relset)
Regards,
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
Zope-Dev maillist - Zope-Dev@zope.org
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 - can't pickle module objects
Gary Poster wrote: On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote: Hi, I *think* this is a bug in zc.relationship, but I'm not quite sure. I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install plone.app.relations, which depends on zc.relationship 1.0.2. In particular, it subclasses zc.relationship.shared.Container, and stores a zc.relationship.index.Index object in self.relationIndex. Now, the __init__ of zc.relationship.index.Index, which derives from Persistent, contains the code below. In self._relTools and and self._attrs, there are a pile of modules, types and functions being stored. I think these are causing the ZODB to barf. Interestingly, with whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no problem. Any ideas how to work around this, or even why it's a problem in one version of the ZODB but not another? No idea yet. What's the barf's traceback? Mmmm... it seems that zc.relationship 1.1 fixes the issue, but has some other problems (an undefined variable minValues or similar - I haven't got a build with this version in it right now); 2.0dev seems better, albeit a bit scary at pre-alpha. Also, I think 2.0dev *requires* ZODB 3.8, though, which means we have to choose one or the other. Ideally, I'd like a version of plone.relations that works with both ZODB 2.7 and 2.8. I'm still having some problems with zc.relationship 2.0dev interacting with five.intid (which has some special path handling to aq-wrap objects that are turned from key references), though I'm hoping to work around them. The traceback was: File /Users/optilude/.buildout/zope/Zope-2.10.6-final-py2.4/lib/python/ZServer/PubCore/ZServerPublisher.py, line 25, in __init__ response=b) File /Users/optilude/.buildout/zope/Zope-2.10.6-final-py2.4/lib/python/ZPublisher/Publish.py, line 401, in publish_module environ, debug, request, response) File /Users/optilude/.buildout/zope/Zope-2.10.6-final-py2.4/lib/python/ZPublisher/Publish.py, line 202, in publish_module_standard response = publish(request, module_name, after_list, debug=debug) File /Users/optilude/.buildout/eggs/Products.PDBDebugMode-0.2-py2.4.egg/Products/PDBDebugMode/__init__.py, line 47, in pdb_publish mapply=mapply, ) File /Users/optilude/.buildout/zope/Zope-2.10.6-final-py2.4/lib/python/ZPublisher/Publish.py, line 125, in publish transactions_manager.commit() File /Users/optilude/.buildout/zope/Zope-2.10.6-final-py2.4/lib/python/Zope2/App/startup.py, line 238, in commit transaction.commit() File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/transaction/_manager.py, line 93, in commit return self.get().commit() File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/transaction/_transaction.py, line 328, in commit t, v, tb = self._saveAndGetCommitishError() File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/transaction/_transaction.py, line 325, in commit self._commitResources() File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/transaction/_transaction.py, line 424, in _commitResources rm.commit(self) File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/ZODB/Connection.py, line 541, in commit self._commit(transaction) File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/ZODB/Connection.py, line 586, in _commit self._store_objects(ObjectWriter(obj), transaction) File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/ZODB/Connection.py, line 620, in _store_objects p = writer.serialize(obj) # This calls __getstate__ of obj File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/ZODB/serialize.py, line 407, in serialize return self._dump(meta, obj.__getstate__()) File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/ZODB/serialize.py, line 416, in _dump self._p.dump(state) File /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/copy_reg.py, line 69, in _reduce_ex raise TypeError, can't pickle %s objects % base.__name__ TypeError: can't pickle module objects Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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 - can't pickle module objects
Martin Aspeli wrote: Gary Poster wrote: On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote: Hi, I *think* this is a bug in zc.relationship, but I'm not quite sure. I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install plone.app.relations, which depends on zc.relationship 1.0.2. In particular, it subclasses zc.relationship.shared.Container, and stores a zc.relationship.index.Index object in self.relationIndex. Now, the __init__ of zc.relationship.index.Index, which derives from Persistent, contains the code below. In self._relTools and and self._attrs, there are a pile of modules, types and functions being stored. I think these are causing the ZODB to barf. Interestingly, with whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no problem. Any ideas how to work around this, or even why it's a problem in one version of the ZODB but not another? No idea yet. What's the barf's traceback? Mmmm... it seems that zc.relationship 1.1 fixes the issue, but has some other problems (an undefined variable minValues or similar - I haven't got a build with this version in it right now); 2.0dev seems better, albeit a bit scary at pre-alpha. Also, I think 2.0dev *requires* ZODB 3.8, though, which means we have to choose one or the other. Ideally, I'd like a version of plone.relations that works with both ZODB 2.7 and 2.8. I meant ZODB 3.7 and 3.8, of course. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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 - can't pickle module objects
Hi Gary, zc.relationship 2.0 trunk is now essentially a wrapping of zc.relation code for backwards compatibility. I see. But 2.0dev on pypi isn't? What's the story behind zc.relation and the evolution of zc.relationship? You guys are the main clients for zc.relationship at this point, I suspect. Possibly, yes. ;-) As I see it, your relatively reasonable options are these: - MOST WORK: Move the plone.relation code to depend on zc.relation. There is an upgrade path for the old indexes. You would need to copy over the old zc.relationship relationship containers to the Plone package. IIRC, Alec's tests of those bits were good, and you could just keep the bits from zc.relationship you needed. ZODB module path issues in legacy databases would be among the more annoying bits of this approach, though we all know the usual solutions there. I think we'd need Alec to find the time to do this if it's to happen, but it does sound like the better option. - LESS WORK: See how zc.relationship trunk works for you. If it makes the code happy, I can release it or help you to do so. It's certainly been sitting around long enough. Then at least you are sitting (indirectly) on top of zc.relation, the package that (for instance) Martijn F.'s Grok work exercises. This would be my preferred compromise between effort and migration. The problem here is that it probably does depend on ZODB 3.8, and I'd rather not make the zc.relation code support the older spellings, so that's probably out for you unless you want to make a concrete counter-proposal in this regard. Well, having a version that only works with ZODB 3.8 isn't *terrible*, it's just annoying. If and when Plone actually ships with five.intid and plone.relations, it'll be on ZODB 3.8 anyway. It's just a bit more work for people wanting to use it. - LEAST WORK: Figure out what's wrong with zc.relationship 1.1. What you described sounds trivial to fix, and I don't have any ethical issues over only supporting the most recent release of the 1.x line, so I don't want to think about the earlier releases. I suspect this is what you want. We can make a 1.1.1 release and you can move on. Hopefully. Do we know that zc.relationship 1.1 works with both ZODB versions? What's the difference between 1.1.1 and 2.0dev on pypi? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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 - can't pickle module objects
Hi Gary, Thanks for being so helpful! What's the difference between 1.1.1 and 2.0dev on pypi? I intended that 1.1.1 would simply make the absolutely minimal changes necessary for you to be able to use the 1.1 branch. It would not have any of the 2.x changes at all. But we're saying that 2.0dev is a very different beast to the trunk that could eventually become 2.0, right? 2.0dev doesn't have a zc.relation dependency, for example. I'm not sure what else there may be in 2.0dev that's useful, of course. I think we need to hear from Alec on what makes most sense for plone.relations. I care pretty much only about the plone.relations API, so I'm sure either of your three options could work. However, I have no idea how hard it'd be in practice to move closer to zc.relation. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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 - can't pickle module objects
Gary Poster wrote: Hopefully. Do we know that zc.relationship 1.1 works with both ZODB versions? That would be a significant point of its existence, so I certainly hope so. I'm 80%+ confident that it does, and would regard not supporting 3.7 as a bug that I'd be willing to fix. Right... so I've just fixed the errors Pyflakes found with zc.relationship 1.1 branch. This now works reliably for my ZODB 3.8.1 build. However, it won't install in my ZODB 3.7 environment, because of this line in setup.py: 'ZODB3 = 3.8dev', Was that an intentional minimum? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
