- Zope-Dev - Zope lists

A permanent log for buildouts
by David Pratt 15 Apr '08

15 Apr '08

Has anyone already setup a more permanent log for buildouts. I am wanting a more permanent record of what has happened when buildout is run. I believe this likely ought to be part of zc.buildout so that you identify a buildout.log location. Many thanks. Regards, David

3 3

buildout not setting exit status
by Adam GROSZER 14 Apr '08

14 Apr '08

Hello, Making a mistake in setup.py like this: ... 'foo.bar [test]' 'foo.lib', ... (note the missing ,) Makes buildout unhappy: """ Develop: '...' error in foo.other setup command: 'extras_require' must be a dictionary whose values are strings or lists of strings containing valid project/version requirement specifiers. While: Installing. Processing develop directory '...'. An internal error occured due to a bug in either zc.buildout or in a recipe being used: AssertionError: """ So far not bad. I made an error I got an error. Problem is that if this is used together with buildBOT, buildbot just continues because buildout does not set exit status "1" on this error. Usually creates nothing, so buildbot will miss the "bin/test". -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Unthinking, idle, wild, and young, I laughed and danced and talked and sung. - Princess Amelia

1 0

coding style: using zapi recommended?
by yuppie 14 Apr '08

14 Apr '08

Hi! Products.Five.browser.adding is basically a copy of zope.app.container.browser.adding. Over time they became more out of sync than necessary. I'd like to fix that, but have one question: In the Five version from zope.app import zapi factory = zapi.getUtility(IFactory, type_name) was replaced by import zope.component factory = zope.component.getUtility(IFactory, type_name) (http://svn.zope.org/Products.Five/trunk/browser/adding.py?rev=67820&r1=6772…) Was this a code modernization that should be ported to zope.app.container? Or should I revert the change in Products.Five? Keeping two different versions makes it unnecessarily hard to read the diffs. Personally, I prefer yet an other version: from zope.component import getUtility factory = getUtility(IFactory, type_name) But I don't want to change both files if there is no recommended version. Maybe we don't need a strict policy for this, but some guidance would be nice to have. Any opinions? Any guidelines I missed? Cheers, Yuppie

3 2

Zope Tests: 5 OK
by Zope Tests Summarizer 14 Apr '08

14 Apr '08

Summary of messages to the zope-tests list. Period Sun Apr 13 11:00:00 2008 UTC to Mon Apr 14 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Sun Apr 13 21:01:36 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009400.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sun Apr 13 21:03:08 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009401.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sun Apr 13 21:04:38 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009402.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sun Apr 13 21:06:08 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009403.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sun Apr 13 21:07:39 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009404.html

1 0

[Launchpad] Permissions for changing status of a ticket?
by Andreas Jung 14 Apr '08

14 Apr '08

Hi, last night, roughly 20 tickets of the Zope 2 tracker were marked as Invalid by a person (never heard its name) which is no part of the Zope 2 developers group on LP. Independent of each ticket I am a bit surprised that obviously any authenticated LP user is able to change the workflow state of a ticket. Is there a configuration option on LP for changing this behavior? Andreas

2 1

Zope Tests: 5 OK
by Zope Tests Summarizer 13 Apr '08

13 Apr '08

Summary of messages to the zope-tests list. Period Sat Apr 12 11:00:00 2008 UTC to Sun Apr 13 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Sat Apr 12 20:55:49 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009395.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sat Apr 12 20:57:19 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009396.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sat Apr 12 20:58:49 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009397.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sat Apr 12 21:00:19 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009398.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sat Apr 12 21:01:50 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009399.html

1 0

Zope Tests: 5 OK
by Zope Tests Summarizer 12 Apr '08

12 Apr '08

Summary of messages to the zope-tests list. Period Fri Apr 11 11:00:00 2008 UTC to Sat Apr 12 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Fri Apr 11 20:55:15 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009390.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Fri Apr 11 20:56:45 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009391.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Fri Apr 11 20:58:15 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009392.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Fri Apr 11 20:59:45 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009393.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Fri Apr 11 21:01:16 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009394.html

1 0

straighting out the SQLAlchemy integration mess
by Martijn Faassen 11 Apr '08

11 Apr '08

Hi there, [I originally picked this up on a thread on zope3-users, but this deserves its own thread here] There are at least three approaches to SQLAlchemy integration with Zope: * z3c.zalchemy (Christian Theune) * z3c.sqlalchemy (Andreas Jung) * collective.lead (Laurence Rowe) All of these are in various states of brokenness. z3c.zalchemy doesn't work with SQLAlchemy trunk. collective.lead works with it, but only if you check out a particular branch, and not with sqlite. Quite possibly z3c.sqlalchemy has a release that actually works. One out of three is not bad... :) Then there's also mentions about WSGI-based integration, and I think in Plone, Alchemist probably also does its own integration... There must be a reason for this proliferation of approaches. What is it? We all get along, don't we? I know that the various packages are taking code and approaches from each other too. Can't we work together more and at least come up with *one* package that works? Perhaps factor out some low-level commonality than then all share? Criticize one of the other packages until you're satisfied, and then retire your own package perhaps? I know the various packages add on their own approaches to configuration and might offer higher level container approaches. Those could be in different packages, sharing a foundation. In the end, I hope we will end up with just *one* integration layer, that is released, that works with Zope 2 and Zope 3 and a recent release of SQLAlchemy, that is documented, and that people know about. We can then offer packages on top of this that offer extra features. Regards, Martijn

12 38

[zope.testing.doctest] a nasty surprise
by Dieter Maurer 11 Apr '08

11 Apr '08

As the community (apparently) strongly favors "doctest" over "unittest", I wrote my first test based on "zope.testing.doctest". And promptly, I was badly surprised.... In order to analyse a difficult problem, I added "from dm.pdb import zpdb; zpdb.set_trace()" in the doctest ("dm.pdb.zpdb" is my Zope aware PDB extension) -- and got a "TypeError: set_trace requires at least one argument, 0 given". Now, I know the "zpdb.set_trace()" does not want any arguments. I moved the line from the doctest code into the failing infrastructure code -- same "TypeError". I called "help(zpdb.set_trace)" and got: Help on function set_trace in module zope.testing.doctest: set_trace(self) Apparently, "doctest" has overridden "zpdb.set_trace" in an incompatible way.... I will rewrite my test as "unittest" and probably avoid in the future "zope.testing.doctest" whenever possible. -- Dieter

4 6

What happened to the infrae.subversion and py eggs?
by Maurits van Rees 11 Apr '08

11 Apr '08

Hi, Sorry, I don't know where best to ask this question, but it is about buildout, so I guess it could be called on-topic on the zope dev list. Since about one day I have problems with buildouts using the infrae.subversion and py eggs. The problem can be seen with a standard buildout. Well, a plone 3 buildout anyway: paster create -t plone3_buildout In the created buildout.cfg I added this section and included it in the parts section: =========================================================== [productcheckouts] recipe = infrae.subversion urls = =========================================================== This does not do anything really, but it should be enough to demonstrate the problem that surfaces when running bin/buildout -v: =========================================================== ... Installing 'infrae.subversion'. We have no distributions for infrae.subversion that satisfies 'infrae.subversion'. Getting distribution for 'infrae.subversion'. Got infrae.subversion 1.0dev-r28201. Picked: infrae.subversion = 1.0dev-r28201 Getting required 'py==0.9.0' required by infrae.subversion 1.0dev-r28201. We have no distributions for py that satisfies 'py==0.9.0'. Getting distribution for 'py==0.9.0'. While: Installing. Getting section productcheckouts. Initializing section productcheckouts. Installing recipe infrae.subversion. Getting distribution for 'py==0.9.0'. Error: Couldn't find a distribution for 'py==0.9.0'. =========================================================== At least, that happens when I do not yet have py-0.9.0-py2.4.egg in my egg cache; no complaints when I already have that one. Has something changed in the py egg? Other explanations for this error? Meanwhile in a virtualenv I can do this without errors: bin/easy_install py==0.9.0 Under the theory that the problem might be caused by the latest version of the infrae.subversion recipe (released a few days ago I think) having a wrong dependency or so, I pin this recipe to a previous version that I know was on the cheeseshop last week as I got it from there: =========================================================== versions = versions [versions] infrae.subversion = 1.0dev-r27844 =========================================================== Then it can't find that version of the egg. Well, my buildout could not find it this afternoon, but of course now the reverse demonstration effect strikes back and it goes fine: =========================================================== Installing 'infrae.subversion'. We have no distributions for infrae.subversion that satisfies 'infrae.subversion==1.0dev-r27844'. Getting distribution for 'infrae.subversion==1.0dev-r27844'. Got infrae.subversion 1.0dev-r27844. Getting required 'py' required by infrae.subversion 1.0dev-r27844. Picked: py = 0.9.1 =========================================================== But this page does not exist: http://pypi.python.org/pypi/infrae.subversion/1.0dev-r27844 and it is not listed here: http://pypi.python.org/simple/infrae.subversion So where does buildout get that egg now? I emptied my egg cache. Luckily for demonstration purposes this at least fails in a virtualenv: =========================================================== $ bin/easy_install infrae.subversion==1.0dev_r27844 Searching for infrae.subversion==1.0dev-r27844 Reading http://pypi.python.org/simple/infrae.subversion/ Reading https://svn.infrae.com/buildout/infrae.buildout/trunk/ No local packages or download links found for infrae.subversion==1.0dev-r27844 error: Could not find suitable distribution for Requirement.parse('infrae.subversion==1.0dev-r27844') =========================================================== So has that version of the egg been removed from the cheeseshop? And can it be brought back? I have buildouts that are pinned to that version for stability and I would like those to work half a year from now (or in fact tomorrow) in case I have to rebuild those buildouts on a new server. You never know when that meteor will hit your data center. ;-) Has anyone else seen this? -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl]

7 9