October 2006 - Zope-Dev

Moving ZopeVersionControl to subversion?
by Wichert Akkerman 13 Dec '06

13 Dec '06

I noticed that ZopeVersionControl is still actively maintained in CVS. Would its maintainers mind moving it to subversion? That would make it a lot easier for us to include it in the Plone 3.0 bundle. Wichert. -- Wichert Akkerman <wichert(a)wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.

6 8

[Fwd: XML export/import is cool! (Was Re: [Zope-dev] Deprecating XML export/import?)]
by Alexei Ustyuzhaninov 06 Nov '06

06 Nov '06

Hi! I would like to resurrect this thread with my own recent experience. My problem was to spread a set of zodb objects over several zope installations. Every installation required some slight modifications to be applied to original objects (such as usernames and passwords). So I decided to export the original data in an xml dump and write a small application which modifies the dump as necessary before import. But to my distress I couldn't import neither a modified dump nor even the original dump. The process failed with UnicodeDecodeError exception. After some investigation I realized what was the problem (at least in my case). The xml parser extracts all texts as unicode strings. But among them are base64-encoded strings which are decoded into non-unicode strings containing binary data. Of course this data can't be decoded by any codec. The code in ppml.py sometimes concatenates the raw and unicode strings and this raises UnicodeDecodeError. I worked this around by converting the unicode strings into non-unicode ones. Please look at the patch attached. Zope version 2.9.4. -- Best regards, Alexei On 25. March 2006 21:40:48 +0100 Yoshinori Okuji <yo at nexedi.com> wrote: > On Saturday 25 March 2006 15:56, Andreas Jung wrote: >> Zope 2.7 throws a BadPickleGet, 12 exception, Zope 2.8 throws >> BadPickleGet, 13 and Zope 2.9 raises the described UnicodeDecodeError. >> I don't expect that the import functionality works for even more complex >> objects. So I consider the whole functionality as totally broken. The >> generated XML might be useful to perform any processing outside Zope but >> using it for re-importing it into another Zope systems definitely does >> _not_ work. So if the functionality should remain in Zope then it should >> be fixed >> for Zope 2.10 lately. > > Here is a quick patch for this problem (against 2.9.1). There were two > different problems: > > - the id attributes were not generated, because the conditional was > reverse. > > - unlike xmllib, expat always returns Unicode data, so simply > concatenating binary values generates Unicode objects with non-ascii > characters. >

5 5

Re: [z3-five] RFC: The future of Products.Five
by Andreas Jung 01 Nov '06

01 Nov '06

--On 30. Oktober 2006 00:01:33 +0100 Philipp von Weitershausen <philipp(a)weitershausen.de> wrote: > > * It is unclear to me at this point what Zope 2's egg story will be. I > *hope* that 2.11 will get the same egg story as the Zope 3.4 that ships > with it does, though noone has talked about eggifying Zope 2 yet. We > should probably do that. > > What are our benefits from a Z2 Eggification. Eggification is basically about packaging and distribution of components with little dependencies in order to re-use them in other contexts. However most components of Zope 2 are heavily dependent on others. Or are we talking about using Zope 3 eggs within Zope 2 as part of the Zope 2 distribution process? Andreas

3 5

Re: RFC: The future of Products.Five(green eggs and zope)
by Daniel Nouri 31 Oct '06

31 Oct '06

Tres Seaver wrote: > Daniel Nouri wrote: >>> whit wrote: >>> <snap> >>>> We still have to handle the Products issue for add ons(mcdonc, donde >>>> estamos con Basketos?). But if Basket is added to 2.11, this might not >>>> be such a big deal. >>> >From what I know, Basket has been abandoned and there's even no good >>> reason for using it. Inside a workingenv you can just go and install >>> egged Products without problems. > > Basket gives Zope the framework to tickle the 'initialize' entry point > in eggs, which is *not* unnecessary AFAIK. 'intialize' will be called for eggs that use the Products namespace package. If the Product lives outside of Products, it must use the 'five:registerPackage' directive so that its 'initialize' is called. One thing to note is that if you install such an egg that has a Products namespace system-wide, it will be 'initialize'd in every Zope instance. So it's advisable to 1) not use the Products namespace package and rely on 'five:registerPackage' if you need 'initialize' and 2) use workingenv or zc.buildout to install the eggs. Daniel

2 2

Zope Tests: 9 OK
by Zope Tests Summarizer 31 Oct '06

31 Oct '06

Summary of messages to the zope-tests list. Period Mon Oct 30 11:00:02 2006 UTC to Tue Oct 31 11:00:02 2006 UTC. There were 9 messages: 9 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Mon Oct 30 21:24:15 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006431.html Subject: OK : Zope-2.6 Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Oct 30 21:25:45 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006432.html Subject: OK : Zope-2.7 Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Oct 30 21:27:15 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006433.html Subject: OK : Zope-2.7 Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 30 21:28:45 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006434.html Subject: OK : Zope-2.8 Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Oct 30 21:30:15 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006435.html Subject: OK : Zope-2.8 Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 30 21:31:45 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006436.html Subject: OK : Zope-2.9 Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 30 21:33:15 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006437.html Subject: OK : Zope-2.10 Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 30 21:34:45 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006438.html Subject: OK : Zope-trunk Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 30 21:36:15 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006439.html

1 0

Re: [z3-five] RFC: The future of Products.Five
by Lennart Regebro 31 Oct '06

31 Oct '06

I don't mind making Products.Five smaller. And I don't mind making loads of small packages called five.something either. That said, I think it's important to make as much of zope3 work under zope2, so any zope3 package included in the zope2 distribution should also have it's corresponding five package included, if it exists. That means, that unless you are planning to not include most of Zope3 in Zope2.12, most five packages should be included as well. And if you don't include most of Zope3, then I think most people using Five will be very confused. So I suspect that the hope of not having to maintain stuff is somewhat overly hopeful. ;)

2 2

Re: RFC: The future of Products.Five(green eggs and zope)
by whit 30 Oct '06

30 Oct '06

Philipp von Weitershausen wrote: <snip /> > I don't think all of these things should go into the Products.Five > anymore, for several reasons: > > * We're trying to get away from writing products and into writing Python > packages that can e.g. be installed as eggs. > > * Some of these things are not essential to bringing Zope 3 technology > into Zope 2 (e.g. like the intid stuff), so it may be questionable > whether it should ship with Zope 2/Five out of the box. > > * Starting with Zope 2.10, Products.Five is actually getting smaller > which is a trend I would like to continue to see. And if I manage to > land my Acquisition refactoring in 2.11, Products.Five will pretty soon > decrease in size tremendously, and there are also other things in > Products.Five that should really be in Zope 2 proper (e.g. OFS). +1 to this logic > Proposal > -------- > > So, what I'm proposing is to feature-freeze the Products.Five package > and just basically keep making it work for future Zope versions. Five > 1.6 (current trunk) will work for Zope 2.11 (current trunk), Five 1.7 > for 2.12, etc. So, essentially there won't be Five feature releases in > between anymore, which means we can put Products.Five into the > Zope/lib/python/Products proper. > > New stuff will be added in standard Python packages that may or may not > ship with Zope 2, Plone or whoever needs them. I personally almost don't > care, it's really only about defining the right egg dependencies in > Plone 3.0 or Zope 2.11, I would assume (see also 'Risks' below). This > seems like the release manager's job who would include stuff based on > requests from the community and package maintainer's recommendations. > > The namespace for these packages should probably be 'five', as we > already have five.intid and five.customerize and we are, after all, the > Five project. +1 > > Advantages > ---------- > > * We'll be able to use stuff we get for Python packages for free, such > as installation via eggs, Cheeseshop presence and much less majyck for > initialization. > > * Stuff that we create as part of the Five project does not necessarily > have to end up in Zope 2. Currently, stuff added to Products.Five > eventually always ends up in some Zope 2 release which means we'll have > to maintain it forever, no matter how crappy it turns out to be (e.g. > Products.Five.site). flipped around, it would be nice to see the crufty features in Five moved out to their own packages, to enable BBB *if needed*. this is similar to nuxeo's XYZonFive product pattern, but easy_install-able. > * Development of certain components can move much faster than even Five. > New things like five.intid or five.customerize can be experimented with > and already be in the right place if they turn out to be stable. If not, > they won't harm Products.Five, either. Individual packages rather than > one big one also reduces the amount of work that has to be done by the > Five release manager (IOW my work ;)). would like to note that other packages in Zope2 also need this ability to release asynchronously from Zope2's schedule; ZopeTestCase in particular comes to mind(Testing should be a namespace package imho). > > Risks > ----- > > * If five.* packages need ZCML config (and I know some will), they will > either have to be included the Zope 3 way (site.zcml or package-includes > slug in your instance's 'etc' directory), or we need to come up with an > approach that Zope 2 people are more comfortable with. I think an egg > entry point would be a compelling solution. big +1 here. would love to use paste deploy to configure my zope instance. There are plans to do this > in Zope 3 even so that you can provide configuration from Python instead > of ZCML. I expect this to land in Zope 3.4 which means we should be able > to take advantage of it in 2.11. I will defer to other's here but say this: I'd rather have better tools to configure with than more options in the configuration language. > * It is unclear to me at this point what Zope 2's egg story will be. I > *hope* that 2.11 will get the same egg story as the Zope 3.4 that ships > with it does, though noone has talked about eggifying Zope 2 yet. We > should probably do that. re zope2 egg story: some talk has occurred thanks to goldegg and general irritation suffered by myself, rocky, nouri and others. Tres and McDonc have definitely plumbed the ugly depths of zope2 thinking about this problem for goldegg. Nouri has run the plone stack as an egg; I've run Zope2 as an egg. re my experience, I made a somewhat indecipherable post about my experiences with easy_install-ing zope from svn with workingenv. To reiterate, the results are pretty cool: all of zope is installed into your workingenv/lib/python, all your scripts(repozo, mkinstance, etc) are installed into your workingenv/bin . Some minor edits are required to make the scripts find the proper libs(due to SOFTWARE_HOME path expectations) and the site skeleton disappear but really, it's darn close to working as an egg. workingenv takes care of the nasty "where should my zope stuff go in relation to the real python world" question. it's likely that you could use setup_tools prefixing to run multiple different versions of zope in the same env; or just simply make a 2.10 env for your 2.10 instance. this means that the "egg story" really doesn't have to happen inside zope(except for wort removal on the Zope2 package). It can just use a well thought out existing python egg story: workingenv(see http://bfhammer.blogspot.com/2006/09/bootstrapenvironment.html for more info). Perhaps if we want to spruce it up a bit, zopectl could handle workingenv's "source bin/activate" and maybe alias the command "install" to the workingenv's easy_install from the zopectl prompt. The distribution could just be a small setup script for zopectl w/ a workingenv recipe that sets up the equivalent of the software home. We still have to handle the Products issue for add ons(mcdonc, donde estamos con Basketos?). But if Basket is added to 2.11, this might not be such a big deal. this probably more of a separate proposal on "what should the Zope2 egg story be?" so if you have feeling, reply as such. -w

1 0

Zope Tests: 8 OK, 1 Failed
by Zope Tests Summarizer 30 Oct '06

30 Oct '06

Summary of messages to the zope-tests list. Period Sun Oct 29 11:00:02 2006 UTC to Mon Oct 30 11:00:02 2006 UTC. There were 9 messages: 9 from Zope Unit Tests. Test failures ------------- Subject: FAILED (errors=1) : Zope-trunk Python-2.4.3 : Linux From: Zope Unit Tests Date: Sun Oct 29 21:37:08 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006430.html Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Sun Oct 29 21:25:06 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006422.html Subject: OK : Zope-2.6 Python-2.3.5 : Linux From: Zope Unit Tests Date: Sun Oct 29 21:26:37 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006423.html Subject: OK : Zope-2.7 Python-2.3.5 : Linux From: Zope Unit Tests Date: Sun Oct 29 21:28:07 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006424.html Subject: OK : Zope-2.7 Python-2.4.3 : Linux From: Zope Unit Tests Date: Sun Oct 29 21:29:37 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006425.html Subject: OK : Zope-2.8 Python-2.3.5 : Linux From: Zope Unit Tests Date: Sun Oct 29 21:31:08 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006426.html Subject: OK : Zope-2.8 Python-2.4.3 : Linux From: Zope Unit Tests Date: Sun Oct 29 21:32:38 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006427.html Subject: OK : Zope-2.9 Python-2.4.3 : Linux From: Zope Unit Tests Date: Sun Oct 29 21:34:08 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006428.html Subject: OK : Zope-2.10 Python-2.4.3 : Linux From: Zope Unit Tests Date: Sun Oct 29 21:35:38 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006429.html

1 0

Re: RFC: The future of Products.Five
by Rocky Burt 30 Oct '06

30 Oct '06

On Mon, 2006-30-10 at 00:01 +0100, Philipp von Weitershausen wrote: > Proposal > -------- > > So, what I'm proposing is to feature-freeze the Products.Five package > and just basically keep making it work for future Zope versions. Five > 1.6 (current trunk) will work for Zope 2.11 (current trunk), Five 1.7 > for 2.12, etc. So, essentially there won't be Five feature releases in > between anymore, which means we can put Products.Five into the > Zope/lib/python/Products proper. +1 > New stuff will be added in standard Python packages that may or may not > ship with Zope 2, Plone or whoever needs them. I personally almost don't > care, it's really only about defining the right egg dependencies in > Plone 3.0 or Zope 2.11, I would assume (see also 'Risks' below). This > seems like the release manager's job who would include stuff based on > requests from the community and package maintainer's recommendations. +0 We're really not sure what the story here is yet... trying to sort things out. > The namespace for these packages should probably be 'five', as we > already have five.intid and five.customerize and we are, after all, the > Five project. +1 > Advantages > ---------- > > * We'll be able to use stuff we get for Python packages for free, such > as installation via eggs, Cheeseshop presence and much less majyck for > initialization. terrific. > * Stuff that we create as part of the Five project does not necessarily > have to end up in Zope 2. Currently, stuff added to Products.Five > eventually always ends up in some Zope 2 release which means we'll have > to maintain it forever, no matter how crappy it turns out to be (e.g. > Products.Five.site). great. > * Development of certain components can move much faster than even Five. > New things like five.intid or five.customerize can be experimented with > and already be in the right place if they turn out to be stable. If not, > they won't harm Products.Five, either. Individual packages rather than > one big one also reduces the amount of work that has to be done by the > Five release manager (IOW my work ;)). great. > Risks > ----- > > * If five.* packages need ZCML config (and I know some will), they will > either have to be included the Zope 3 way (site.zcml or package-includes > slug in your instance's 'etc' directory), or we need to come up with an > approach that Zope 2 people are more comfortable with. I think an egg > entry point would be a compelling solution. There are plans to do this > in Zope 3 even so that you can provide configuration from Python instead > of ZCML. I expect this to land in Zope 3.4 which means we should be able > to take advantage of it in 2.11. Interesting, but definitely needs more thought. > * It is unclear to me at this point what Zope 2's egg story will be. I > *hope* that 2.11 will get the same egg story as the Zope 3.4 that ships > with it does, though noone has talked about eggifying Zope 2 yet. We > should probably do that. Indeed. Zope's eggification story needs to be straightened out. We see some of this with Jim's proposals for Zope 3. I'm inclined to watch the discussion for Zope 3 and hopefully see a good solution unfold (of course I won't be afraid to share my opinion). My suspicion is that Zope 2's eggification story will be very similar (best case scenario: identical) to Zope 3's eggification story. So this is one place where I say let Zope 3 work it out first :) > Comments welcome :) Well... constructive comments at least... :) Regards, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net

1 0

Zope Tests: 8 OK, 1 Failed
by Zope Tests Summarizer 29 Oct '06

29 Oct '06

Summary of messages to the zope-tests list. Period Mon Oct 23 10:00:02 2006 UTC to Tue Oct 24 10:00:02 2006 UTC. There were 9 messages: 9 from Zope Unit Tests. Test failures ------------- Subject: FAILED (errors=1) : Zope-trunk Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 23 21:35:18 EDT 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006371.html Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Mon Oct 23 21:23:17 EDT 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006363.html Subject: OK : Zope-2.6 Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Oct 23 21:24:47 EDT 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006364.html Subject: OK : Zope-2.7 Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Oct 23 21:26:17 EDT 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006365.html Subject: OK : Zope-2.7 Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 23 21:27:48 EDT 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006366.html Subject: OK : Zope-2.8 Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Oct 23 21:29:18 EDT 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006367.html Subject: OK : Zope-2.8 Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 23 21:30:48 EDT 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006368.html Subject: OK : Zope-2.9 Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 23 21:32:18 EDT 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006369.html Subject: OK : Zope-2.10 Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 23 21:33:48 EDT 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006370.html

5 7