April 2009 - Zope-Dev

zc.relationship - can't pickle module objects
by Martin Aspeli 09 Nov '09

09 Nov '09

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

3 15

XML-RPC does not work under the paster process
by Michael Haubenwallner 26 May '09

26 May '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When using paste.httpserver instead of twisted.wsgi server zope.publisher.xmlrpc.XMLRPCRequest.processInputs() hangs when reading 0 Bytes from the request (wsgi.input <socket._fileobject object>). As i found the zope.publisher.http.HTTPInputStream.readlines() signature was changed 3 years ago from readlines(self, hint=None) to readlines(self, hint=0) http://svn.zope.org/Zope3/trunk/src/zope/publisher/http.py?rev=66941&r1=669… Do you think we could revert the change? Bugs reported: zopeproject: https://bugs.launchpad.net/zope3/+bug/283089 grokproject: https://bugs.launchpad.net/grok/+bug/332063 Regards Michael - -- http://blog.d2m.at http://planetzope.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJvRDVl0uAvQJUKVYRAuMZAJ0eZBKjoInmx5CigwgjUf2gDpQyXQCfTBh5 IVbnn5i1v5WAwGPJxUJWCZs= =+cQ+ -----END PGP SIGNATURE-----

3 6

zc.recipe.cmmi shared builds
by Wolfgang Schnerring 18 May '09

18 May '09

Hello, I'd like to extend zc.recipe.cmmi to support shared build directories. Use case example: we use lxml in a lot of our projects, which currently means having to build libxml and libxslt over and over again, since the buildout needs to be standalone and thus can't depend on them being installed on the system. But while that's a necessity for deployment, it's really annoying for development. Plan of attack: Introduce an option "shared" (defaults to False). If that is set, a) calculate HASH as a hash of the recipe's current options (e. g. configure parameters, environment variables) b) perform the cmmi in ${buildout:download-cache}/cmmi/build/<HASH>, if that directory is not present yet. (Probably needs a little thought about how to differentiate between "present and has a complete build" and "present but we errored out") Any thoughts? Thanks, Wolfgang -- Wolfgang Schnerring · ws(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development

5 7

z3c.form: Problem validating file uploads
by Michael Howitz 17 May '09

17 May '09

Hi, I'm using a trunk version of z3c.form and have the following situation: In my interface I have a zope.schema.Bytes field. z3c.form.converter.FileUploadDataConverter.toFieldValue returns z3c.form.interfaces.NOT_CHANGED when I do not upload a file. z3c.form.validator.SimpleFieldValidator.validate fails later on as the value (z3c.form.interfaces.NOT_CHANGED) is not of type str (which is required by the Bytes field). I created a branch in svn to show the behavior. (z3c.form/branches/ icemac_validate_NOT_CHANGED) I'm not sure how to fix this generally, some possible solutions come to my mind, but each idea has its own problems: 1) Create a special validator for zope.schema.Bytes + z3c.form.interfaces.IFileWidget which knows how to handle NOT_CHANGED. This does not seem to be a really general solution and might have the same problems like the following ideas. 2) When z3c.form.validator.SimpleFieldValidator.validate is called with NOT_CHANGED as value, try to look up the value on the context object. This fails on AddForms as the context there is the parent object. 3) When z3c.form.validator.SimpleFieldValidator.validate is called with NOT_CHANGED as value, do not validate hoping the previous value was valid. This approach fails with AddForms, too, when the Bytes field is required. (The missing-value-error does not get raised.) Anyone having an idea for a possibly working solution? Yours sincerely, -- Michael Howitz · mh(a)gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development

2 3

zc.buildout broken
by Roger Ineichen 08 May '09

08 May '09

Hi everybody Ran 367 tests with 50 failures and 1 errors in 8 minutes 14.891 seconds. The latest trunk of zc.buildout is completly broken. At least on windows. Can someone check this on linux? Regards Roger Ineichen _____________________________ END OF MESSAGE

8 14

dropping Python 2.4 support in the Zope Toolkit?
by Martijn Faassen 07 May '09

07 May '09

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. Regards, Martijn

14 61

Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
by Andreas Jung 01 May '09

01 May '09

On Sun, Apr 26, 2009 at 18:46, Martin Aspeli <optilude(a)gmail.com> wrote: > 2009/4/27 Andreas Jung <lists(a)zopyx.com>: > > > You might approach Hanno since he has committer rights. > > I do too... Does that mean you're +1 ? I have no problem with the changes. You have my blessing if Hanno is ok with the changes from the Plone prospective. Andreas

7 13

Proposal: set __parent__ and __name__ in Zope 2.12 OFS
by Martin Aspeli 01 May '09

01 May '09

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

10 17

Zope 2.12 from buildout with no funky recipes: success!
by Chris Withers 01 May '09

01 May '09

Hi All, I've committed the tiny change necessary to be able to run Zope 2.12 from a (relatively) simple buildout. I've attached the buildout.cfg, zope.conf.in and zeo.conf.in I've been using to this message. It would be nicer if the initialization bits could go away and the Zope2 egg could declare the runzope and zopectl scripts. Where do the runzeo and zeoctl entry points belong? I'd guess in the ZODB egg, but would they get built when specifying just the zope2 egg? The above may be problematic: how would we pass the location of zeo.conf and zope.conf to the start scripts? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

2 3

zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues
by Gary Poster 30 Apr '09

30 Apr '09

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) iw.recipe.template (Ingeniweb) inquant.recipe.textfile (Stefan Eletzhofer) z3c.recipe.template (Uli Fouquet) buildout_script (Nathan Yergler) z3c.recipe.filetemplate (Philipp von Weitershausen) First, on the basis of this list, it strikes me that a lot of people want this functionality. Putting template support into zc.buildout itself would be nice. I envision some APIs (like the ones in easy_install.py that zc.recipe.egg uses) that other recipes could use easily. I would even want recipes like the zc.recipe.egg script recipe to allow specifying initialization code by identifying a template (i.e., ``initialization_template = buildout_templates/foo``, which would parse the given template and insert the code the same way the ``initialization`` parameter works). Second, there's no clear winner at the moment. I happened to find z3c.recipe.template, buildout_script, and z3c.recipe.filetemplate first. On the basis of those three, and the comments that z3c.recipe.template made about collective.recipe.template, iw.recipe.template, and inquant.recipe.textfile, I decided to settle on z3c.recipe.template to be the package to which I would contribute. It has tests, a variable substitution approach that seems to work well with buildout, and recent development activity. However, on starting to hack on its documentation to sketch the changes I wanted, I gradually realized that this was a fork of collective.recipe.template. Since collective.recipe.template is listed as BSD in setup.py (though I saw no explicit licensing otherwise), placing z3c.recipe.template in the zope.org ZPL-only repository is problematic. 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. But meanwhile, I'm concerned about the state of z3c.recipe.template. IMO, Uli and Wichert should try to reconcile the licensing and forking issues (with Uli taking the lead in those discussions, ideally, since he is the one who forked). z3c.recipe.template should be removed from the zope.org repository, unless/until the licensing story is cleaned up. And maybe we can start to settle on a common template approach soon. This should be a problem that is solved for buildout canonically, IMO. I'll be happy to try and see if my features are generally interesting, once I make them. (Note: I could write about this on the distutils list but I'm not already subscribed there, and I suspect I have a better chance of catching some authors of the pertinent recipes over here, and some of this is about the zope.org repo.) Gary

6 10