- Zope-Dev - Zope lists

Zope Tests: 7 OK
by Zope Tests Summarizer 18 Jan '07

18 Jan '07

Summary of messages to the zope-tests list. Period Wed Jan 17 12:00:00 2007 UTC to Thu Jan 18 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Wed Jan 17 21:08:37 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007062.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Jan 17 21:10:08 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007063.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Jan 17 21:11:38 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007064.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Jan 17 21:13:08 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007065.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Jan 17 21:14:39 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007066.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Jan 17 21:16:09 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007067.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Jan 17 21:17:39 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007068.html

1 0

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Hanno Schlichting 18 Jan '07

18 Jan '07

Martijn Faassen wrote: > Hey, > > Just some feedback in case you haven't gotten this already: I have > problem running bin/buildout as it seems to fail getting workingenv.py > from the cheeseshop: > > zc.buildout.easy_install: Getting new distribution for workingenv.py>=0.3 > Page at http://www.python.org/pypi/workingenv.py/ links to .py file(s) > without version info; an index scan is required. > error: Couldn't find a setup script in /tmp/tmpDRKwglget_dist/workingenv.py > Traceback (most recent call last): Ah I had that problem with buildout as well. I could install it using my global easy_install though. Probably we need to append some '#egg=project-version' here according to http://peak.telecommunity.com/DevCenter/setuptools#dependencies-that-aren-t… as workingenv is distributed as a single Python script rather than a package. Hanno

1 0

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Hanno Schlichting 18 Jan '07

18 Jan '07

Hi, sorry, I'm catching up with my mail slowly these days... Martijn Faassen wrote: > Hey, > > Martin Aspeli wrote: >> Martijn Faassen wrote: > >>> If you used a pure buildout solution you'd have gotten an ImportError on >>> elementtree that you'd need to fix by altering a setup.py somewhere. >> I did get an ImportError. The way I fixed it was by running >> 'easy_install elementtree'; perhaps I should've updated the buildout or >> the deps of one of the eggs instead. > > Right, you'd want to write this dependency down, probably in an egg > dependency if you can do it, so it gets pulled in automatically. Yep, we should note both elementree (required by Archetypes, more precisely Marshall anyways since Plone 2.5) and PIL (python-imaging) as dependencies somewhere in ploneout. > [snip] >>> So if you have a project with a setup.py called 'foo' under the buildout >>> root, you'd say this in buildout.cfg: >>> >>> [buildout] >>> develop = foo >> Aha, didn't know that. Interesting. >> >> How does that work if I then decide to add another package to the >> buildout though? Do I then end up wiping everything and starting from >> scratch (e.g. blank zope instance part) just to get that one egg to be >> installed? Scary... > > If you change the configuration of your Zope instance to include that > egg then yes, your instance will be rebuilt. Note that the object > database is in another part, so it won't be wiped. Yeah, scary. It would > be less scary if Zope instances were less complicated and if > configuration were maintained somewhere else. One thing to correct here, is that I haven't found the time to make the Data.fs and independent part, so while in the Zope3 recipes, the instance and the database are separated, they are currently not in the Zope2 recipes. There's an XXX comment in the Zope2 instance recipe, that marks the commented out section of the recipe, that would need to be adjusted. > [snip] >> I guess I don't understand how I'm supposed to use this *during >> development* where I may be finding, creating, adding and removing my >> own eggs or other old-style Products throughout the life of the problem. > > You change your dependencies in the respective setup.py files. > Considering old style Products I have no idea what the solution strategy > is of the recipes involved. Be careful here, as I noted I did not understand the way buildout's egg and develop section should really work, so my current Zope2 recipes don't use that at all. So if you are confused at some points, that's because you are not talking about the same approach ;) >> - Having to re-create the Data.fs each time is unacceptable > > It shouldn't do that unless you change the configuration of the data > section specifically. At least that's the case for the Zope 3 recipes. See above, the independent database part is still missing. >> - Having to wait half an hour while buildout re-downloads and >> re-configures everything is hardly great > > That's not what it should be doing - the Zope 2 software home shouldn't > be touched, for instance. Creating a new instance doesn't cost a lot of > time, though. Indeed, as noted somewhere I even introduces a local offline option for the Zope2 checkout recipe, so it shouldn't get downloaded or updated at all, once checked out, unless buildout thinks some configuration of that part has changed and it wipes the part completely. I'm not sure but it might be that the current recipes being in development mode themselves cause trouble here. I'm not sure how exactly buildout determines the checksum of a recipe, but if the SVN revision number is somehow involved, updating the ploneout checkout itself could cause some trouble, as the recipes are included in them as well. But this is only a wild guess ;) > You can stop it from doing redownloads (if you know it isn't necessary) > by doing: > > bin/buildout buildout:offline=true Yep, you need to know the above command. In general it will not attempt to update any part, but if buildout determines that a parts options or the underlying recipe has changed it will still wipe and rebuild from scratch. As a general comment, the current ploneout config should probably be changed to at least not include any eggs as parts, but should use buildouts approach of putting their checkout in src/ instead not managing them as a part and including all those in the develop section of buildout. Hanno (still catching up with this thread...)

1 0

synonym for getMultiAdapter
by Chris Withers 18 Jan '07

18 Jan '07

Hi All, I'd love to see: IWhatever(multi=(obj1,obj2,obj3)) ...as a sysnonym for getMultiAdapter((obj1,obj2,obj3),IWhatever) What do people feel about this? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0

[testrunner] Problems with optparse?
by Andreas Jung 17 Jan '07

17 Jan '07

suxmac2:~/sandboxes/Zope/Zope ajung$ bin/zopectl test -t Products.Five Hi, I encounter some strange problems with the testrunner (testing the Zope 2 trunk): Running tests via: /opt/python-2.4.4/bin/python /Users/ajung_data/sandboxes/Zope/Zope/bin/test.py -v --config-file /Users/ajung_data/sandboxes/Zope/Zope/etc/zope.conf -t Products.Five Parsing /Users/ajung_data/sandboxes/Zope/Zope/etc/zope.conf Running tests at level 1 Test-module import failures: Module: zope.testbrowser.tests Traceback (most recent call last): File "/Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/testbrowser/__init__.py", line 20, in ? from testing import Browser File "/Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/testbrowser/testing.py", line 27, in ? from zope.testbrowser import browser File "/Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/testbrowser/browser.py", line 19, in ? from test import pystone File "/Users/ajung_data/sandboxes/Zope/Zope/test.py", line 103, in ? help="""\ File "/opt/python-2.4.4/lib/python2.4/optparse.py", line 938, in add_option self._check_conflict(option) File "/opt/python-2.4.4/lib/python2.4/optparse.py", line 913, in _check_conflict option) OptionConflictError: option --config-file: conflicting option string(s): --config-file Another error: running 'zopectl test -D' tries to debug optparse itself Running tests via: /opt/python-2.4.4/bin/python /Users/ajung_data/sandboxes/Zope/Zope/bin/test.py -v --config-file /Users/ajung_data/sandboxes/Zope/Zope/etc/zope.conf -D Parsing /Users/ajung_data/sandboxes/Zope/Zope/etc/zope.conf Running tests at level 1 optparse.OptionConflictError: option --config-file: conflicting option string(s): --config-file > /opt/python-2.4.4/lib/python2.4/optparse.py(913)_check_conflict() -> option) (Pdb) Any ideas? Andreas

1 0

Zope Tests: 7 OK
by Zope Tests Summarizer 17 Jan '07

17 Jan '07

Summary of messages to the zope-tests list. Period Tue Jan 16 12:00:00 2007 UTC to Wed Jan 17 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Tue Jan 16 21:08:13 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007055.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Tue Jan 16 21:09:43 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007056.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Tue Jan 16 21:11:14 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007057.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Tue Jan 16 21:12:44 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007058.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Tue Jan 16 21:14:14 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007059.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Tue Jan 16 21:15:44 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007060.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Tue Jan 16 21:17:14 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007061.html

1 0

Zope Tests: 7 OK
by Zope Tests Summarizer 16 Jan '07

16 Jan '07

Summary of messages to the zope-tests list. Period Mon Jan 15 12:00:00 2007 UTC to Tue Jan 16 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Mon Jan 15 21:11:21 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007048.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Jan 15 21:12:52 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007049.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Jan 15 21:14:22 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007050.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Jan 15 21:15:52 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007051.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Jan 15 21:17:22 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007052.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Jan 15 21:18:52 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007053.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Jan 15 21:20:23 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007054.html

1 0

Zope Tests: 6 OK, 1 Failed
by Zope Tests Summarizer 15 Jan '07

15 Jan '07

Summary of messages to the zope-tests list. Period Sun Jan 14 12:00:00 2007 UTC to Mon Jan 15 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Test failures ------------- Subject: FAILED (failures=1) : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Jan 14 21:16:41 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007047.html Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Sun Jan 14 21:07:40 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007041.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Jan 14 21:09:10 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007042.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Jan 14 21:10:40 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007043.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Jan 14 21:12:10 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007044.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Jan 14 21:13:40 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007045.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Jan 14 21:15:11 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007046.html

1 0

ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Hanno Schlichting 15 Jan '07

15 Jan '07

Hi. (I already send this mail through gmane but it didn't show up on the lists for half a day. So it might show up twice later on, sorry.) Spawning of a discussion on plone-devel (http://thread.gmane.org/gmane.comp.web.zope.plone.devel/13865/focus=13865) about how to use eggs and their features like entrypoints in our current development environments, we discussed some of the available options. As I think this is a common problem for all Zope2 developers I'll post this to zope-devel as well. In order to get a better understanding of how one of the possible solutions called zc.buildout works, I started to write all those recipes one would need to set up a full development environment for Plone 3.0. Quite frankly most of the work was already done by Jim and I only needed to adjust some of his Zope3 specific recipes ;) A full Plone 3.0 environment includes (should be similar for other projects): - Checking out the Zope 2.10 branch and compiling the C extensions - Creating a Zope instance - Checking out one or many SVN bundles containing a multitude of Products and moving these into the instance - Checking out a product from CVS and moving it into the instance (hopefully you don't need to do that anymore :) - Installing some external Python packages (elementtree, PIL, py-openid, ...) and making those available in the Zope instance - Somehow putting 19 Python packages in development mode into the instance (these are the ones we have written ourselves) I have put those recipes that where necessary to automate all of these steps into the ploneout package (https://svn.plone.org/svn/plone/ploneout/trunk) but intend to move them to svn.zope.org as soon as I have commit rights and should people be interested in them. The four recipes that I have written, are able to check-out Zope2 and compile it inplace, create a Zope2 instance, check out a bundle (any folder really) from either SVN or CVS and finally enable a folder as a working environment (http://www.python.org/pypi/workingenv.py) Among the more useful features are: - All recipes support both the global as well as a part specific offline option, so you can tell each checkout separately, that it should not do anything by itself after the first checkout. This can cut down the time needed to update the buildout quite enormously. - The Zope2 instance recipe takes a product-set option. You can give it a list of bundles and it will symlink all folders included in each bundle into the instance. - The Zope2 instance recipe also supports the zcml option known from it's Zope3 counterpart, so you can create ZCML slugs automatically. - The workingenv recipe takes any folder (usually a Zope2 instance) and turns it into a workingenv, supporting all the command line options workingenv itself support. Among these is also the requirements option that lets you specify a text file (url or local file) which includes dependencies to be installed into the workingenv. - And as another special option the workingenv recipe supports an additional develop-set option which like the Zope instance product-set option takes a bundle (any local folder really) and calls setup.py develop on any package it finds in there. Usually this installs all those packages into INSTANCE_HOME/lib/python (the workingenv) in development mode. If you combine all of those recipes (like it's done in the ploneout/buildout.cfg) you get a working Zope2 instance and have various ways of installing both products and packages into it. Currently you won't get a running Plone 3.0 instance as not all of the required newly written Python packages are setuptools enabled yet. What's missing now is a more seamless integration of the packages or eggs installed into the workingenv and those installed in the global buildout itself. Secondly in order to be productive one would need some more nice scripts in the global buildout/bin that would allow to start the Zope instance, run tests from any development egg, Product or Zope itself reliably, a recipe to automatically populate the ZODB with some initial content like a Plone site... and the usual Windows support that isn't yet there but could be easily added if people show any interest in those recipes. Currently this was only an exercise to support development environments, for deployment you would want to use released versions which would need some new recipes. As this is my first attempt to use zc.buildout I might have made some obvious mistakes not recognizing it's potential or working against its design. Please tell me about those mistakes :) My current conclusion for using zc.buildout is that it makes setting up a complete environment from scratch a lot easier and should help developers that are not that advanced yet or are not developers at all. Think of the first day at a sprint for example, where you spent time helping people to get a running system or doing that with your designers. For advanced developers it constrains them in a way they might not find acceptable - we all have our different ways of managing our projects right now. If you use buildout for a complex project you can either use it or not, you cannot really use only parts of it. Comments and suggestions are welcome as always ;) Hanno

1 0

[Trunk] some tests will fail
by Andreas Jung 14 Jan '07

14 Jan '07

I added/extended some tests that will fail because of errors in Zope. One failure is related to the FTP acquisition bug (#2261). Two other failures are related to rendering ZPTs with content_type text/xml. -aj

2 1