December 2009 - Zope-Dev

zope.contenttype on PyPI is messed up
by Fabio Tranchitella 31 Dec '09

31 Dec '09

Can somebody please fix zope.contettype on PyPI? We had a 3.5.0 release, and somebody uploaded a 3.4.3 release which should have been 3.5.1. I don't have the rights for it. Best regards, Fabio

4 3

Zope Tests: 6 OK
by Zope Tests Summarizer 31 Dec '09

31 Dec '09

Summary of messages to the zope-tests list. Period Wed Dec 30 12:00:00 2009 UTC to Thu Dec 31 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Dec 30 20:36:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013293.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Dec 30 20:38:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013294.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 30 20:40:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013295.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 30 20:42:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013296.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 30 20:44:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013297.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 30 20:46:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013298.html

1 0

Top-level namespace package for Zope 2 ?
by Baiju M 31 Dec '09

31 Dec '09

Hi, I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: "zope.app.*", "grokcore.*", "repoze.bfg.*" ? Well, I don't have any name suggestion :) Regards, Baiju M

4 5

Re: [Zope-dev] SVN: Zope/branches/2.10/doc/CHANGES.txt - fixed improper usage of the IF_MODIFIED_SINCE header inside
by Tres Seaver 31 Dec '09

31 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote: > Log message for revision 107357: > - fixed improper usage of the IF_MODIFIED_SINCE header inside > Five/browser/resource.py > > > Changed: > U Zope/branches/2.10/doc/CHANGES.txt > > -=- > Modified: Zope/branches/2.10/doc/CHANGES.txt > =================================================================== > --- Zope/branches/2.10/doc/CHANGES.txt 2009-12-30 13:16:54 UTC (rev 107356) > +++ Zope/branches/2.10/doc/CHANGES.txt 2009-12-30 13:19:39 UTC (rev 107357) > @@ -4,6 +4,14 @@ > Change information for previous versions of Zope can be found in the > file HISTORY.txt. > > + Zope 2.10.11 (unreleased) > + > + Bugs fixed > + > + - fixed improper usage of the IF_MODIFIED_SINCE header inside > + Five/browser/resource.py > + > + > Zope 2.10.10 (2009/12/22) No fix for this issue has landed yet on the 2.10 branch. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks8FtEACgkQ+gerLs4ltQ5LyQCeL/KfsJFy8yK8q3SNdGeqW8/9 6wgAoKnSPP4v455jXr5h/Xka8biA5C4I =HuBu -----END PGP SIGNATURE-----

1 0

Re: [Zope-dev] SVN: Zope/branches/2.11/ - Fixed improper handling of IF_MODIFIED_SINCE header
by Tres Seaver 31 Dec '09

31 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote: > Log message for revision 107356: > - Fixed improper handling of IF_MODIFIED_SINCE header > inside Five/browser/resource.py > > > Changed: > U Zope/branches/2.11/doc/CHANGES.txt > U Zope/branches/2.11/lib/python/Products/Five/browser/resource.py What, no test? How do you know you got the speling right? And why use 'request.environ.get()' instead of the original OFS.Image spelling, 'request.get_header()'? 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks8FS8ACgkQ+gerLs4ltQ5UewCgnwP21URcTj/AfX1tRl6vsKj2 cQIAn3oPGaIX4VOK8UIErPu8Hk9kHpLu =bAkx -----END PGP SIGNATURE-----

1 0

removing zope.app from the ZTK
by Martijn Faassen 30 Dec '09

30 Dec '09

Hi there, Fastest summary: * removing responsibility from the ZTK, yes, but not like this. Quick summary: * I agree we should dump most, perhaps all, of the code that is in zope.app.* from the ZTK. Most of these packages will likely eventually become unmaintained. * We as a community have a responsibility to help the users of our software to help get to a world with a vastly smaller set of zope packages. We can't just ignore that responsibility. * we can make a plan about when we will declare a lot of packages without support, after we've had some more experience with upgrading code. Longer: Here's my position on the role of zope.app within the ZTK and in our community. We as the Zope community have been maintaining Zope 3 for years now. We have a lot of software that depends on it. Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. As part of the dependency refactoring project, we've been factoring code out of zope.app.* packages that we do use and leaving the old zope.app.* packages behind. A philosophical point: just because we have a dependency structure that *allows* us to remove zope.app.* from the dependency tree of the ZTK doesn't mean that only zope.* contains useful code that can be shared between our community. It's been a convenient shortcut to think in this way, but it isn't necessarily the case that we're done moving code out of zope.app.* into zope.*. I'll ignore this point below and assume that zope.app.* only contains old stuff that we don't want to maintain in the future. Recently the zope.app.* packages were entirely removed from the ZTK. That we wish to remove zope.app.* from the ZTK at some point follows from the previous discussion, but as a community, I think we've certainly done this step too fast. Since this is a *big* change and was done without sufficient discussion, I've reverted this change and added these packages back into the ZTK, in the "under review" section where they were before, and back to the versions list. We need to maintain zope.app.* for the time being to help people off zope.app. We can't just drop the ball on this and offer no support. The argument was made that the Zope 2 project has already taken care of this, and that other projects that use Zope 3 should also maintain their own backwards compatibility list separately and just work out their own upgrade stories. This is exactly one of those jobs we should do centrally, and not delegate to subcommunities. That's neglecting our responsibility as a community and ignoring a *value* of our community. In what form we should maintain the zope.app.* packages? I can see a construction where the main ZTK consists only of non-zope.app packages and that we, as ZTK developers, maintain a separate project for zope.app.*. This way we can continue to maintain and test this project as a community, and help people with a smooth upgrade. We cannot just stop testing whether this works, or stop maintaining versions that work together. And that's what we did. We can make a plan as to when we *will* officially drop support for these packages, or hand over maintainership to others, etc, and how we will help our community to get there. Our plan doesn't need to be perfect; we can expect some difficulty in this upgrade, but we should at least make a reasonable attempt. Regards, Martijn

8 32

Re: [Zope-dev] [ZODB-Dev] Splitting a large ZODB file storage - any light-weight approach?
by Jens Vagelpohl 30 Dec '09

30 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote: > Hi there, > > we have some huge ZODB file storage (60-80 GB each) and we want > to split the storage into a number of smaller storage (easier > to handle for backup and packing). The storages themselves only > contain a few (Zope 2) folders - let's say folders A, B, C - > within the root and we want to create seperate storages for A, B, C. > > Is there some easier approach than using the Zope 2 CopyManager API > for moving data around. The ZODB storage iterator API comes to my mind... > is this a suitable approach or is there some other light-weight approach > (compared to using CopyManager API)? Why move any data between ZODBs at all? In this situation I would try the following: - create a new empty ZODB. This one holds the root. - copy the old Data.fs into three new storage server buildouts. Attach to each with a ZEO client and delete the folders you do not need in that particular storage in the ZMI or via zopectl debug. - pack each storage so the deleted data gets trashed and the files shrink. - mount the "folder" storages into the new empty root using mount points on the clients that will use the storages. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks7CpEACgkQRAx5nvEhZLKjYgCdGI71f/yNJS3EIpZxkyFVBmSe qhMAoJ8RBK2eq27P67Iki4h4MYMZ1kZB =FC8f -----END PGP SIGNATURE-----

3 2

Zope Tests: 6 OK
by Zope Tests Summarizer 30 Dec '09

30 Dec '09

Summary of messages to the zope-tests list. Period Tue Dec 29 12:00:00 2009 UTC to Wed Dec 30 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Dec 29 20:38:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013287.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Dec 29 20:40:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013288.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 29 20:42:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013289.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 29 20:44:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013290.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 29 20:46:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013291.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 29 20:48:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013292.html

1 0

Zope 2.12.2 SyntaxError on installation
by Marius Gedminas 29 Dec '09

29 Dec '09

Following the guide at http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances I get the following error: mg@platonas:~/src/akl-website-z2.12-experiment $ python2.5 bootstrap.py Creating directory '/home/mg/src/akl-website-z2.12-experiment/bin'. Creating directory '/home/mg/src/akl-website-z2.12-experiment/parts'. Creating directory '/home/mg/src/akl-website-z2.12-experiment/develop-eggs'. Generated script '/home/mg/src/akl-website-z2.12-experiment/bin/buildout'. mg@platonas:~/src/akl-website-z2.12-experiment $ time bin/buildout Upgraded: zc.buildout version 1.4.3, setuptools version 0.6c11; restarting. Generated script '/home/mg/src/akl-website-z2.12-experiment/bin/buildout'. Installing instance. Getting distribution for 'Zope2'. src/AccessControl/cAccessControl.c:598: warning: ‘intargfunc’ is deprecated src/AccessControl/cAccessControl.c:599: warning: ‘intargfunc’ is deprecated src/AccessControl/cAccessControl.c:600: warning: ‘intintargfunc’ is deprecated src/AccessControl/cAccessControl.c:606: warning: ‘intargfunc’ is deprecated src/Record/_Record.c:340: warning: ‘intargfunc’ is deprecated src/Record/_Record.c:341: warning: ‘intargfunc’ is deprecated src/Record/_Record.c:342: warning: ‘intintargfunc’ is deprecated File "build/bdist.linux-i686/egg/Zope2/utilities/load_site.py", line 248 body = ("<html><head><title><dtml-var title_or_id></title> ^ SyntaxError: EOL while scanning single-quoted string File "/home/mg/tmp/buildout-eggs/tmprWUwxL/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/utilities/load_site.py", line 248 body = ("<html><head><title><dtml-var title_or_id></title> ^ SyntaxError: EOL while scanning single-quoted string Got Zope2 2.12.2. which seems to be https://bugs.launchpad.net/zope2/+bug/501265 Then buildout proceeds as if nothing is wrong. Getting distribution for 'zope.app.publication==3.7.0'. Got zope.app.publication 3.7.0. Getting distribution for 'zope.app.form==3.8.1'. Got zope.app.form 3.8.1. Getting distribution for 'zope.viewlet==3.5.0'. Got zope.viewlet 3.5.0. Getting distribution for 'zope.contentprovider==3.5.0'. Got zope.contentprovider 3.5.0. Getting distribution for 'zope.component==3.7.1'. Got zope.component 3.7.1. Getting distribution for 'zLOG==2.11.1'. Got zLOG 2.11.1. Getting distribution for 'tempstorage==2.11.2'. Got tempstorage 2.11.2. Getting distribution for 'Persistence==2.11.1'. Got Persistence 2.11.1. Getting distribution for 'ExtensionClass==2.11.3'. Got ExtensionClass 2.11.3. Getting distribution for 'DateTime==2.12.0'. Got DateTime 2.12.0. Getting distribution for 'Acquisition==2.12.4'. Got Acquisition 2.12.4. Getting distribution for 'zope.app.testing==3.6.2'. Got zope.app.testing 3.6.2. Getting distribution for 'zope.app.appsetup==3.11'. Got zope.app.appsetup 3.11. Generated script '/home/mg/src/akl-website-z2.12-experiment/bin/runzope'. Generated script '/home/mg/src/akl-website-z2.12-experiment/bin/zopectl'. Generated interpreter '/home/mg/src/akl-website-z2.12-experiment/bin/py'. After that, it refuses to create a Data.fs and start up: mg@platonas:~/src/akl-website-z2.12-experiment $ bin/runzope Traceback (most recent call last): File "bin/runzope", line 93, in <module> Zope2.Startup.run.run() File "/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/run.py", line 21, in run starter.prepare() File "/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/__init__.py", line 87, in prepare self.startZope() File "/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/__init__.py", line 264, in startZope Zope2.startup() File "/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/__init__.py", line 47, in startup _startup() File "/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/App/startup.py", line 72, in startup DB = dbtab.getDatabase('/', is_root=1) File "/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/datatypes.py", line 283, in getDatabase name = self.getName(mount_path) File "/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/datatypes.py", line 300, in getName self._mountPathError(mount_path) File "/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/datatypes.py", line 273, in _mountPathError "No root database configured") ZConfig.ConfigurationError: No root database configured Huh? Result of that load_site.py error, or a missing manual step that I should have known to do despite it being not mentioned in the installation docs? I was brave enough to specify INSTANCEHOME as '.' in my zope.conf, because I strongly believe hardcoding absolute paths is dumb. mg@platonas:~/src/akl-website-z2.12-experiment $ cat etc/zope.conf %define INSTANCE . python $INSTANCE/bin/py instancehome $INSTANCE Cheers! Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development

4 14

moving the zope.app.* packages out of the ZTK: towards a plan
by Martijn Faassen 29 Dec '09

29 Dec '09

Hi there, Let me sketch out some ideas for a plan: * we create a new project, zopeapp, with the same structure as the zopetoolkit (sans documentation) * we pull the zope.app.* packages from the ZTK and move them into zopeapp. * we make sure we have a way to regularly run the zopeapp tests in conjunction with the ZTK. * we then move towards a release of ZTK 1.0 (see Hanno's mail for lots of things we need to work out) * we also release zopeapp 1.0 in conjunction with it. This is just a backwards compatibility KGSish thing. We explicitly don't strive to document it, etc. * we announce that we strive to deprecate what's in zopeapp 1.0 and that we expect users to shift to use ZTK packages as much as possible and report back any difficulties they have with this. * this will help us determine whether there is still useful code left in zopeapp that we wish to salvage into the ZTK or otherwise maintain. * this will also help us determine which packages in zopeapp are more generally useful, and strive to isolate them from the rest of zopeapp. zope.formlib is an example of this. * depending on our experiences in Zope 2, Zope 3 and Grok apps we can decide whether we can put zopeapp in the deep freeze: not maintain it anymore. * we then also look into shunting away the zope.app.* packages from the top-level SVN into an "this is old stuff area" by that time. Note that we also have a long-standing idea of a "wider KGS" which contains the ZTK plus perhaps zopeapp plus more, such as z3c.form. This is a related exercise. Once we have some discussion we can hopefully flesh out this plan, put in some dates and such, and put the plan in the Zope Toolkit documentatino. Regards, Martijn

2 3