March 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

Re: [Zope-dev] [Zope3-checkins] [Checkins] SVN: zope.app.component/trunk/setup.py set missing minimum version
by Wichert Akkerman 12 Apr '09

12 Apr '09

Previously Stephan Richter wrote: > On Saturday 14 March 2009, Michael Howitz wrote: > > Log message for revision 98113: > > set missing minimum version > > > > > > Changed: > > U zope.app.component/trunk/setup.py > > > > -=- > > Modified: zope.app.component/trunk/setup.py > > =================================================================== > > --- zope.app.component/trunk/setup.py 2009-03-14 19:56:47 UTC (rev 98112) > > +++ zope.app.component/trunk/setup.py 2009-03-14 20:14:47 UTC (rev 98113) > > @@ -78,7 +78,7 @@ > > 'zope.interface', > > 'zope.lifecycleevent', > > 'zope.location>3.4.0b1', > > - 'zope.publisher', > > + 'zope.publisher>=3.6.0', > > 'zope.schema', > > 'zope.security', > > 'zope.traversing', > > Please, please, please no versions in setup.py. If the package does not work with an older version of zope.publisher than imho that version restriction *has* to be in setup.py. Wichert. -- Wichert Akkerman <wichert(a)wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.

16 62

[Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]
by Tres Seaver 05 Apr '09

05 Apr '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: [Bug 343079] [NEW] Broken distribution (2009-03-15) Date: Sun, 15 Mar 2009 07:42:00 -0000 From: dmaurer <dieter(a)handshake.de> Reply-To: Bug 343079 <343079(a)bugs.launchpad.net> To: tseaver(a)palladion.com References: <20090315074200.12457.19313.malonedeb(a)potassium.ubuntu.com> Public bug reported: The current (2009-03-12) PyPI distribution for Zope2 2.12.0a1 is broken. 'easy_install'ing it leads to version conflicts for 'zope.component' (3.5.1 versus 3.6.0) in the call of 'mkzopeinstance'. ** Affects: zope2 Importance: Undecided Status: New The breakage is due to the release of the new zope.prinipalregistry egg. We should probably manage a Zope2 indes and tell people to use it when running easy_install, because PyPI is not suitable for the task given setuptools' "incremental requirements discovery" design. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJvT4A+gerLs4ltQ4RAo0LAJ4q83+Ua0hEQUb5ecOhU8IufTcXnQCfV9wd 6eFVN+pmQTi0CW+ki8f+f8M= =zsxY -----END PGP SIGNATURE-----

5 16

Zope and Cygwin
by Cesar Canassa 01 Apr '09

01 Apr '09

Hi all, I am trying to run Zope using cygwin and Windows XP. I started by downloading the Python 2.4.6 sources and compiling it with: ./configure make && make install After that I downloaded the Zope-2.11.2-final sources and compiled it with: ./configure --with-python=/usr/local/bin/python make && make install The compilation went smoothly so I created a instance and started the server with the runzope script. The script returned this error: $ ./runzope Traceback (most recent call last): File "/opt/Zope-2.11/lib/python/Zope2/Startup/run.py", line 56, in ? run() File "/opt/Zope-2.11/lib/python/Zope2/Startup/run.py", line 21, in run starter.prepare() File "/opt/Zope-2.11/lib/python/Zope2/Startup/__init__.py", line 109, in prepare self.startZope() File "/opt/Zope-2.11/lib/python/Zope2/Startup/__init__.py", line 300, in startZope Zope2.startup() File "/opt/Zope-2.11/lib/python/Zope2/__init__.py", line 47, in startup _startup() File "/opt/Zope-2.11/lib/python/Zope2/App/startup.py", line 105, in startup Globals.VersionNameName) File "/opt/Zope-2.11/lib/python/App/ZApplication.py", line 32, in __init__ if not root.has_key(name): File "/opt/Zope-2.11/lib/python/ZODB/Connection.py", line 811, in setstate self._setstate(obj) File "/opt/Zope-2.11/lib/python/ZODB/Connection.py", line 870, in _setstate self._reader.setGhostState(obj, p) File "/opt/Zope-2.11/lib/python/ZODB/serialize.py", line 604, in setGhostState state = self.getState(pickle) File "/opt/Zope-2.11/lib/python/ZODB/serialize.py", line 597, in getState return unpickler.load() File "/opt/Zope-2.11/lib/python/ZODB/serialize.py", line 471, in _persistent_load return self.load_oid(reference) File "/opt/Zope-2.11/lib/python/ZODB/serialize.py", line 537, in load_oid return self._conn.get(oid) File "/opt/Zope-2.11/lib/python/ZODB/Connection.py", line 245, in get obj = self._reader.getGhost(p) File "/opt/Zope-2.11/lib/python/ZODB/serialize.py", line 591, in getGhost return klass.__new__(klass, *args) TypeError: Acquirer.__new__(Application) is not safe, use Persistence.Persistent.__new__() Am I doing something wrong? Does anyone knows if it's possible to compile Zope with Cygwin? Thanks, Cesar Canassa

3 6

trying out the buildout-based Zope 2.12...
by Chris Withers 31 Mar '09

31 Mar '09

Hey All, I'm trying to get Zope 2.12 working with buildout, in the absence of docs, I thought I'd try: [buildout] parts = zopetest [zopetest] recipe = zc.recipe.egg interpreter = py eggs = zope2 ...and was rewarded with: Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'. wtf? Chris

8 39

snakebite
by Martijn Faassen 30 Mar '09

30 Mar '09

Hi there, Recently there was a project called snakebite revealed: http://www.snakebite.org/ http://mail.python.org/pipermail/python-committers/2009-January/000331.html It's basically a whole bunch of machines that open source projects, in particular Python related ones, can make use of for testing. It's essentially a buildbot farm as I understand it. The announcement says: "Every CPython, Jython, IronPython and PyPy committer will have access to every development server on the network. I’ve also extended the offer to prominent Python projects like Django and Twisted." I think the Zope project counts as a "prominent Python project" and we have a lot of interesting code to test, so perhaps they'll let us in. :) Would people be interested in working on making use of this platform? We could use it for testing of a wide range of packages. Perhaps the ZODB would be an interesting package to start with. If so we should approach snakebite to see whether we can get on board. Regards, Martijn

6 7

Buildbot for Zope 3
by Sebastien Douche 30 Mar '09

30 Mar '09

Hi, sad time for zope 3: http://zope.buildbot.securactive.org/waterfall Tell me if you other things (I want repoze, python and Tarek's distutils). -- Sebastien Douche <sdouche(a)gmail.com>

1 0

progress on Zope 2.12.0a1 from buildout with no funky recipes ; -)
by Chris Withers 30 Mar '09

30 Mar '09

Hey All, I've made some progress on this, here's the buildout: [buildout] parts = zopeinstance extends = versions2.cfg [zopeinstance] recipe = zc.recipe.egg eggs = zope2 entry-points= runzope=Zope2.Startup.run:run zopectl=Zope2.Startup.zopectl:main scripts = runzope zopectl initialization = import sys sys.argv[1:1] = ['-C','${buildout:directory}/etc/zope.conf'] There are 3 other files you need: - versions2.cfg, which is a static copy of: http://svn.zope.org/*checkout*/Zope/tags/2.12.0a1/versions-zope2.cfg (and changed to extend versions3.cfg instead of versions-zope3.cfg) - versions3.cfg, which is a static copy of: http://svn.zope.org/*checkout*/Zope/tags/2.12.0a1/versions-zope3.cfg - zope.conf, which is a minimal zope.conf So, with this, the following will work: - bin/runzope - bin/zopectl fg However, bin/zopectl (start|stop) doesn't work because line 131 of zopectl.py sets zdrun to a hard coded path. I guess we need to generate a script for zdrun that has all the eggs present. Any ideas on the "right" way to do this? I guess we may need to do something similar with zeoctl? cheers, Chris

1 1