Renamed the Zope package to Zope2 and including Zope 3 packages in Zope 2.8
I've just checked in a change on the Zope 2 trunk for Zope 2.8 that renames the Zope package to Zope2. Importing the Zope module is now deprecated, but will be supported until Zope 2.11. When using the Zope head or Zope 2.8, you should import Zope2 instead. Originally, I had intended not to include any Zope 3 packages until Zope 2.9, however, Zope 2.8 has been delayed long enough that I think it makes sense to include some parts of Zope 3 sooner. I also want to use some of the Zope 3 persistent code support, which depends on zope.interface to help get ZClasses working again. I haven't decided which parts of Zope 3 should be included in Zope 2.8 and would like to get input. If you have suggestions on what to include or exclude, please respond here or on the z3-file list, where I am also posting this message. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Mon, Jan 31, 2005 at 10:53:01AM -0500, Jim Fulton wrote: <snip> | I haven't decided | which parts of Zope 3 should be included in Zope 2.8 and would like to | get input. If you have suggestions on what to include or exclude, | please respond here or on the z3-file list, where I am also posting | this message. Whatever we have in Five right now seems like a good subset. I haven't felt need for much more than that anyways. We have: - Adapters - Views - Menus - Some support for auto-generated forms I think the main outstanding issue is interoperability between Zope 3 and Zope 2 Page Templates, which is being investigated. Someone correct me if I missed something. -- Sidnei da Silva <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher <phed> dash: that's the cool part of system programming, programming half-finished programs, and tell others you're finished
... Zope3 packages useful in Zope 2 ...
Sidnei da Silva wrote at 2005-1-31 14:03 -0200:
... Whatever we have in Five right now seems like a good subset. I haven't felt need for much more than that anyways. We have:
- Adapters - Views - Menus - Some support for auto-generated forms
I would like to add: - interface - event -- Dieter
On Mon, Jan 31, 2005 at 07:58:38PM +0100, Dieter Maurer wrote:
... Zope3 packages useful in Zope 2 ...
Sidnei da Silva wrote at 2005-1-31 14:03 -0200:
... Whatever we have in Five right now seems like a good subset. I haven't felt need for much more than that anyways. We have:
- Adapters - Views - Menus - Some support for auto-generated forms
I would like to add:
- interface - event
+1 on all of those from me. However, I will be satisfied with anything that gets released as 2.8 sometime this year ;-) -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
On Mon, Jan 31, 2005 at 07:58:38PM +0100, Dieter Maurer wrote:
... Zope3 packages useful in Zope 2 ...
Sidnei da Silva wrote at 2005-1-31 14:03 -0200:
... Whatever we have in Five right now seems like a good subset. I haven't felt need for much more than that anyways. We have:
- Adapters - Views - Menus - Some support for auto-generated forms
I would like to add:
- interface - event
+1 on all of those from me. However, I will be satisfied with anything that gets released as 2.8 sometime this year ;-)
Absolutely. The top priority, IMO, is getting 2.8 out as soon as we can. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Paul Winkler wrote:
+1 on all of those from me. However, I will be satisfied with anything that gets released as 2.8 sometime this year ;-)
Absolutely. The top priority, IMO, is getting 2.8 out as soon as we can.
Excuse me, but it seems bizarre to me that *if* the top priority is to get Zope 2.8 out the best way to go about it is to add a lot of features to it. The best way to get Zope 2.8 out is to feature freeze it and release it. I recall hearing something about wanting to release Zope 2.8 as soon as possible before, and that was a year ago. Please excuse me of being skeptical this time around too. Regards, Martijn
Martijn Faassen wrote:
Jim Fulton wrote:
Paul Winkler wrote:
+1 on all of those from me. However, I will be satisfied with anything that gets released as 2.8 sometime this year ;-)
Absolutely. The top priority, IMO, is getting 2.8 out as soon as we can.
Excuse me, but it seems bizarre to me that *if* the top priority is to get Zope 2.8 out the best way to go about it is to add a lot of features to it. The best way to get Zope 2.8 out is to feature freeze it and release it.
All I'm talking about is including some existing packages. I'm not proposing any more than that.
I recall hearing something about wanting to release Zope 2.8 as soon as possible before, and that was a year ago. Please excuse me of being skeptical this time around too.
The main blocker was and is the need to get ZClasses working for backward compatibility reasons. I am curreently working on this as I find time. My intent is to try to clean up and use the persistent class support from Zope 3 for this. This code depends on zope.interface, as does the trunk of ZODB. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Sidnei da Silva wrote:
On Mon, Jan 31, 2005 at 10:53:01AM -0500, Jim Fulton wrote: <snip> | I haven't decided | which parts of Zope 3 should be included in Zope 2.8 and would like to | get input. If you have suggestions on what to include or exclude, | please respond here or on the z3-file list, where I am also posting | this message.
Whatever we have in Five right now seems like a good subset. I haven't felt need for much more than that anyways. We have:
- Adapters - Views - Menus - Some support for auto-generated forms
I think the main outstanding issue is interoperability between Zope 3 and Zope 2 Page Templates, which is being investigated.
Someone correct me if I missed something.
But Five has no *need* of this stuff in Zope 2, and I suspect it'll only make our life harder. Either we'll be locked into a stale Zope 2.8 version or we'll have to maintain compatibility with both Zope 3 releases and Zope 2 releases.. If someone can package up the stuff needed for Five and nothing else and wrap it up as a Zope 2 product (that fiddles with the path), fine. That's only to make things more easily deployable. Right now the hard part is however detaching Zope 3 stuff from its dependencies -- for Five you'd need an enormous chunk of Zope 3 in order to make it work. Why bother with it? Regards, Martijn
Martijn Faassen wrote:
That's only to make things more easily deployable. Right now the hard part is however detaching Zope 3 stuff from its dependencies
Really? That's extremely disappointing :-( The most important aim of Zope 3 from my POV was to be able to use as little or as much of it as you want, not suffer dependency hell as we do in Zope 2... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Wednesday 02 February 2005 05:28, Chris Withers wrote:
Martijn Faassen wrote:
That's only to make things more easily deployable. Right now the hard part is however detaching Zope 3 stuff from its dependencies
Really? That's extremely disappointing :-( The most important aim of Zope 3 from my POV was to be able to use as little or as much of it as you want, not suffer dependency hell as we do in Zope 2...
Yes, that is true for packages in zope. However, zope.app was designed as the application server and has thus many dependencies among the packages in zope.app. Note that the srichter-blow-services branch will bring great relief to some of these dependencies. registration, component and site used to have circular imports, but in the branch they all have been merged into zope.app.component, with each module being independent of the others. For example, the registration code does not depend on the local site manager code. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
On Wednesday 02 February 2005 05:28, Chris Withers wrote:
Martijn Faassen wrote:
That's only to make things more easily deployable. Right now the hard part is however detaching Zope 3 stuff from its dependencies
Really? That's extremely disappointing :-( The most important aim of Zope 3 from my POV was to be able to use as little or as much of it as you want, not suffer dependency hell as we do in Zope 2...
Yes, that is true for packages in zope. However, zope.app was designed as the application server and has thus many dependencies among the packages in zope.app.
It's not entirely true for packages in zope either. If you try to extract one you'll likely pull in quite a few others. Detaching the dependencies is however easier. Five has dependencies on zope.app, so to make Five use Zope 2.8 packages would require quite a bit of Zope 3 to be pulled in, or an awful lot of work to prevent it from being pulled in. Presumably only a few packages will be pulled into Zope 2.8 in practice, which means that Five will have to worry about packages from Zope 2.8 and packages from Zope X3 proper, and possible weird combinations and interactions. Not something I'm looking forward to. I wanted this (Zope 3 integration into Zope 2.x) about a year ago, but by now, with the gained experience I have with Five, it seems a lot more trouble than it's worth.
Note that the srichter-blow-services branch will bring great relief to some of these dependencies. registration, component and site used to have circular imports, but in the branch they all have been merged into zope.app.component, with each module being independent of the others. For example, the registration code does not depend on the local site manager code.
Cool. If however that branch will have to be merged before we can use Zope 3 technology in Zope 2, Zope 2.8 will be even more delayed. :) Regards, Martijn
Martijn Faassen wrote: ...
Five has dependencies on zope.app, so to make Five use Zope 2.8 packages would require quite a bit of Zope 3 to be pulled in, or an awful lot of work to prevent it from being pulled in.
I think Zope 3 is at a point where, if there are volunteers, it would be worthwhile to start working on getting things out of zope.app. I have this low-priority "bobo" project, which is about using Zope 3 without using the app server. In the little work I've done on this, it's become clear that lots of things that are in zope.app should move out.
Presumably only a few packages will be pulled into Zope 2.8 in practice, which means that Five will have to worry about packages from Zope 2.8 and packages from Zope X3 proper, and possible weird combinations and interactions. Not something I'm looking forward to.
Understood. There are a few packages however, that Zope 2 can benefit independent of five. These packages are pretty stable so I'm reasonably confident that this needed pose too great a hassel. At least I hope not. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Martijn Faassen wrote: ...
Five has dependencies on zope.app, so to make Five use Zope 2.8 packages would require quite a bit of Zope 3 to be pulled in, or an awful lot of work to prevent it from being pulled in.
I think Zope 3 is at a point where, if there are volunteers, it would be worthwhile to start working on getting things out of zope.app. I have this low-priority "bobo" project, which is about using Zope 3 without using the app server. In the little work I've done on this, it's become clear that lots of things that are in zope.app should move out.
We had similar issues with Five. Early on I tried to replicate zope.app stuff in Five so there was no dependency on zope.app, just on zope. Soon enough we gave that up, and our lives have been easier as a result.
Presumably only a few packages
will be pulled into Zope 2.8 in practice, which means that Five will have to worry about packages from Zope 2.8 and packages from Zope X3 proper, and possible weird combinations and interactions. Not something I'm looking forward to.
Understood. There are a few packages however, that Zope 2 can benefit independent of five. These packages are pretty stable so I'm reasonably confident that this needed pose too great a hassel. At least I hope not.
True, zope.interface would be one, and I guess a few others. You know better than I do which packages are bound to evolve a lot in Zope 3 from now on, and which ones are stable enough. Important is that Zope 3 remains working with the packages in Zope 2.8 as long as possible. Alternatively there could be a knob in Zope 2.8 to turn off the Zope 3 packages included in Zope 2.8, and use those on the Python path itself. I'm not sure how easily that can be accomplished. Regards, Martijn
Stephan Richter wrote:
Yes, that is true for packages in zope.
So, if I understand you correctly, I can use all packages, except those in zope.app, on their own, without having to rely on anything else, right?
However, zope.app was designed as the application server and has thus many dependencies among the packages in zope.app.
Hmmm, that's a shame, there's a lot of things in http://svn.zope.org/Zope3/trunk/src/zope/app/ that look, by name, like I might want to use them without using other stuff: catalog, cache, authentication, apidoc, etc. That said, is it just me or do http://svn.zope.org/Zope3/trunk/src/zope/app/ and http://svn.zope.org/Zope3/trunk/src/zope/ look like there's a LOT of stuff in them? How much of it is "real" and how much of it is cruft? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Thursday 03 February 2005 03:23, Chris Withers wrote:
Stephan Richter wrote:
Yes, that is true for packages in zope.
So, if I understand you correctly, I can use all packages, except those in zope.app, on their own, without having to rely on anything else, right?
However, zope.app was designed as the application server and has thus many dependencies among the packages in zope.app.
Hmmm, that's a shame, there's a lot of things in http://svn.zope.org/Zope3/trunk/src/zope/app/ that look, by name, like I might want to use them without using other stuff:
catalog, An abstraction of this package could be probably moved to zope.
cache Some of the package could be surely moved to zope, but caches are local utilities and as such they depend on zope.app.
authentication I think this package is totally useless outside zope.app, since authentication is bound to the publisher framework, unless of course your own application knows how to use the IAuthentication interface.
apidoc
The reason the API doc tool is so useful is because it is totally custom to Zope 3's app server. It makes many, many assumptions on how the registration directives create factories for views and other components (for example). Except for the some of the interface viewer and the class browser nothing will apply to another application.
That said, is it just me or do http://svn.zope.org/Zope3/trunk/src/zope/app/ and
The reason there are so many packages is that we wanted to factor out as much reusable code as possible into a package. The list is too long to write a comment for each package.
Here is the list from src/zope: app/ - Zope application server. hookable/ - A small package that allows functions to be hookable, i.e. graceful monkey patching. pagetemplate/ - Zope-independent page template code. cachedescriptors/ - I have no clue what this does. i18n/ - I18n and Locale implementation. proxy/ - Basic object-proxy implementation. Similar to context wrappers. component/ - The component architecture. i18nmessageid/ - Message Ids have been separated from i18n, so that some of the zope packages do not depend on i18n, but still have I18n support. configuration/ - ZCML and general configuration implementation. importtool/ - library for the importtool script that determines unused imported objects. publisher/ - Basic Publisher framework (like in Zope 2) dependencytool/ - Library for a tool that checks the dependencies of a package. index/ - Zope-independent index implementation; contains several indices. deprecation/ - Some code to ease marking deprecated code. schema/ - Schema package. tal/ - TAL implementation (equiv. to Zope 2) documenttemplate/ - DTML implementation (equiv. to Zope 2) security/ - Basic security implementation. tales/ - TALES implementation (equiv. to Zope 2) event/ - Redicoulisly simple event implementation (should be in PYthon proper, really) interface/ - Interface package. server/ - The new server code, equiv. to medusa in Zope 2 testing/ - Support for various testing techniques, such as doc file tester. exceptions/ - Standard Zope exceptions. We could probably move those to other packages. modulealias/ - Allows one to register a module under a different path. Good for BBB. structuredtext/ - Class STX implementation. thread/ - Threading support for the servers. fssync/ - FS syncing library. I do not know the state of this. xmlpickle/ - Creates Pickles in XML format, equyiv. to Zope 2 I think.
look like there's a LOT of stuff in them?
I don't think so. A lot of the packages are very small.
How much of it is "real" and how much of it is cruft?
There is not much cruft. We try to clean up regularly. We just decide not to distribute the packages we do not feel comfortable with yet. Please name the packages that you think are cruft... Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Hi, I noticed that Zope 2.x usually comes with bin/zopectl and bin/runzope scripts but no zeo equivalent scritps. Is there a reason for that ? I usually create bin/zeoctl and bin/runzeo to restore the simmetry, which eases management. That was filed in ZC under: http://collector.zope.org/Zope/1388 Is it eligible to Zope 2.8 ? regards, Senra -- Rodrigo Senra MSc Computer Engineer rodsenra@gpr.com.br GPr Sistemas Ltda http://www.gpr.com.br
On Thu, Feb 03, 2005 at 02:36:41PM -0200, Rodrigo Dias Arruda Senra wrote:
Hi,
I noticed that Zope 2.x usually comes with bin/zopectl and bin/runzope scripts but no zeo equivalent scritps. Is there a reason for that ?
What do you mean "usually comes with"? When you install Zope from a source tarball, you can run bin/mkzopeinstance.py to create the Zope scripts, and bin/mkzeoinstance.py to create the ZEO scripts. Maybe what you are really complaining about is that the ./configure; make; make install process doesn't automatically make a ZEO instance? Or maybe that when you make install, the last message is: Zope binaries installed successfully. Now run '/home/pw/tmp/NewZope/bin/mkzopeinstance.py' ... but nothing is said about ZEO?
I usually create bin/zeoctl and bin/runzeo to restore the simmetry, which eases management.
That was filed in ZC under: http://collector.zope.org/Zope/1388
That's about the lack of a ZEO batch file for the windows shell, aka DOS. Different problem. -- Paul Winkler http://www.slinkp.com
[Rodrigo Senra]:
I noticed that Zope 2.x usually comes with bin/zopectl and bin/runzope scripts but no zeo equivalent scritps. Is there a reason for that ?
[Paul Winkler]
What do you mean "usually comes with"? When you install Zope from a source tarball, you can run bin/mkzopeinstance.py to create the Zope scripts, and bin/mkzeoinstance.py to create the ZEO scripts.
Paul, I do apologize. I was accoustomed to "make instance" and totally missed bin/mkzeoinstance.py. That solves the matter. [Paul Winkler]
Maybe what you are really complaining about is that the ./configure; make; make install process doesn't automatically make a ZEO instance?
That is what I *should* be complaining about <wink>! [Paul Winkler]
Or maybe that when you make install, the last message is: Zope binaries installed successfully. Now run '/home/pw/tmp/NewZope/bin/mkzopeinstance.py' ... but nothing is said about ZEO?
Perhaps such a reference would prevented me from making this blunder. =) Obviously I think this is a good idea [Rodrigo Senra]:
That was filed in ZC under: http://collector.zope.org/Zope/1388
[Paul Winkler]
That's about the lack of a ZEO batch file for the windows shell, aka DOS. Different problem.
Indeed! And if I have read that post carefully I could have avoided two blunders, since it mentioned mkzeoinstance.py. lol Thank you. best regrads, Senra -- Rodrigo Senra MSc Computer Engineer rodsenra@gpr.com.br GPr Sistemas Ltda http://www.gpr.com.br
Rodrigo Dias Arruda Senra wrote at 2005-2-3 14:36 -0200:
I noticed that Zope 2.x usually comes with bin/zopectl and bin/runzope scripts but no zeo equivalent scritps. Is there a reason for that ?
They are created by Zope's "make instance" which in turn calls "mkzopeinstance". There is a symmetric "mkzeoinstance". When you call it, it creates the corresponding "zeoctl" and "zeorun" scripts. -- Dieter
Chris Withers wrote:
Stephan Richter wrote:
Yes, that is true for packages in zope.
So, if I understand you correctly, I can use all packages, except those in zope.app, on their own, without having to rely on anything else, right?
No, but we try to restrict dependencies as much as possible. The fact that these are generally useful means that they wre someone likely to depend on each other. For example, zope.interface is obviously widely used. The zope.testing package is also widely used.
However, zope.app was designed as the application server and has thus many dependencies among the packages in zope.app.
Hmmm, that's a shame, there's a lot of things in http://svn.zope.org/Zope3/trunk/src/zope/app/ that look, by name, like I might want to use them without using other stuff: catalog, cache, authentication, apidoc, etc.
When we are initially developing something, it's hard to know whether it will be generaly useful. We try very hard to avoid premature generalization. We also have a rule that anything that depends on zope.app must be in zope.app. The plan and expectation is that, over time, many packages will migrate out of zope.app. I expect that, eventually, zope.app will be much smaller than it is now. That shrinkage will happen over time has people have motivation and time.
That said, is it just me or do http://svn.zope.org/Zope3/trunk/src/zope/app/ and http://svn.zope.org/Zope3/trunk/src/zope/ look like there's a LOT of stuff in them?
Yup, we've done a lot of work.
How much of it is "real" and how much of it is cruft?
There is certainly cruft there, but we've trie dto keep the cruft/real ratio low. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
I agree with Sidnei. Note that diskussions about the Zope2 + Zope3 pagetemplate issue arrived in the conclusion that, the faster we can get Zope3 pagetemplates back ported to Zope2, the happier we will be. ;) I have no idea if that is a big task or not.
On Mon, 31 Jan 2005 19:25:15 +0100, Lennart Regebro <regebro@nuxeo.com> wrote:
Note that diskussions about the Zope2 + Zope3 pagetemplate issue arrived in the conclusion that, the faster we can get Zope3 pagetemplates back ported to Zope2, the happier we will be. ;) I have no idea if that is a big task or not.
That's not my recollection. :-( My goal is that the various packages involved in page template in Zope 2 become facades over the Zope 3 implementation. I'm afraid I've not had any time to work on this; I'm hoping I can spend some time Wednesday evening, though I'm also approaching an important release for Expat. This is all volunteer time. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> Zope Corporation
Fred Drake wrote:
My goal is that the various packages involved in page template in Zope 2 become facades over the Zope 3 implementation.
Same thing, IMO. ;-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Jim Fulton wrote:
I've just checked in a change on the Zope 2 trunk for Zope 2.8 that renames the Zope package to Zope2. Importing the Zope module is now deprecated, but will be supported until Zope 2.11.
Actually, that's 2.10. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
please respond here or on the z3-file list,
Which list is this? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Jim Fulton wrote:
please respond here or on the z3-file list,
Which list is this?
z3-five, of course. :) http://codespeak.net/mailman/listinfo/z3-five Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Originally, I had intended not to include any Zope 3 packages until Zope 2.9, however, Zope 2.8 has been delayed long enough that I think it makes sense to include some parts of Zope 3 sooner. I also want to use some of the Zope 3 persistent code support, which depends on zope.interface to help get ZClasses working again. I haven't decided which parts of Zope 3 should be included in Zope 2.8 and would like to get input. If you have suggestions on what to include or exclude, please respond here or on the z3-file list, where I am also posting this message.
Zope 2.8 should be shipped with all stuff required for Five + some nice gimmicks like the import* helpers from utilities/. zope.interface - Zope3 interfaces are much better than the zope2 stuff zope.component - important for five zope.i18n + zope.i18nmessage - especially the l10n is very useful, also gotcha is working on a way to translate MessageIds in Zope2's ZPublisher. See PlacelessTranslationService Z3MsgId branch (I can't remember the excact name) zope.configuration - zcml is nice zope.importtool - for importtool and importorder, please also include importchecker in ZOPE_HOME/bin. I like it :) zope.schema These modules are easy to add w/o shipping Zope2 with a full installation of Zope3. Much harder but even useful are modules from zope.app like adapter, apidoc, event or the widget stuff for zope.schema. Personally zope.interface and zope.component are the most important and also useful thing I would like to see in Zope2. Christian
Christian Heimes wrote:
Jim Fulton wrote:
Originally, I had intended not to include any Zope 3 packages until Zope 2.9, however, Zope 2.8 has been delayed long enough that I think it makes sense to include some parts of Zope 3 sooner. I also want to use some of the Zope 3 persistent code support, which depends on zope.interface to help get ZClasses working again. I haven't decided which parts of Zope 3 should be included in Zope 2.8 and would like to get input. If you have suggestions on what to include or exclude, please respond here or on the z3-file list, where I am also posting this message.
Zope 2.8 should be shipped with all stuff required for Five + some nice gimmicks like the import* helpers from utilities/.
I wish people much luck detaching the stuff required for Five from Zope 3. I'm certainly not going to waste any time on doing so.
zope.interface - Zope3 interfaces are much better than the zope2 stuff zope.component - important for five zope.i18n + zope.i18nmessage - especially the l10n is very useful, also gotcha is working on a way to translate MessageIds in Zope2's ZPublisher. See PlacelessTranslationService Z3MsgId branch (I can't remember the excact name) zope.configuration - zcml is nice zope.importtool - for importtool and importorder, please also include importchecker in ZOPE_HOME/bin. I like it :) zope.schema
These modules are easy to add w/o shipping Zope2 with a full installation of Zope3. Much harder but even useful are modules from zope.app like adapter, apidoc, event or the widget stuff for zope.schema.
For Five, you're going to need very significant parts of zope.app.
Personally zope.interface and zope.component are the most important and also useful thing I would like to see in Zope2.
Any reason these cannot be distributed as a Zope product? Regards, Martijn
Christian Heimes wrote:
Zope 2.8 should be shipped with all stuff required for Five + some nice gimmicks like the import* helpers from utilities/.
Here are the modules currently directly imported by Five. I'm not counting the things that these modules in turn import: zope.app zope.app.component.interface zope.app.component.metaconfigure zope.app.container.contained zope.app.container.interfaces zope.app.datetimeutils zope.app.event.objectevent zope.app.form.browser.metaconfigure zope.app.form.browser.submit zope.app.form.interfaces zope.app.form.utility zope.app.location zope.app.location.interfaces zope.app.pagetemplate.viewpagetemplatefile zope.app.publisher.browser.globalbrowsermenuservice zope.app.publisher.browser.metadirectives zope.app.publisher.browser.resources zope.app.publisher.browser.viewmeta zope.app.publisher.fileresource zope.app.publisher.pagetemplateresource zope.app.security.interfaces zope.app.traversing.adapters zope.app.traversing.browser.interfaces zope.app.traversing.interfaces zope.component zope.component.factory zope.component.interfaces zope.component.servicenames zope.configuration zope.configuration.exceptions zope.configuration.fields zope.event zope.exceptions zope.interface zope.interface.common.mapping zope.interface.interface zope.interface.interfaces zope.publisher.interfaces.browser zope.schema zope.security.checker zope.security.management zope.tales.pythonexpr -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Would it make sense to have Zope 2.8 include all of the packages below other than zope.app and for Five to supply it's own zope.app? Jim P.S. We definately want zope.testing too. I'm surprised that Five isn't using it. Lennart Regebro wrote:
Christian Heimes wrote:
Zope 2.8 should be shipped with all stuff required for Five + some nice gimmicks like the import* helpers from utilities/.
Here are the modules currently directly imported by Five. I'm not counting the things that these modules in turn import:
zope.app zope.app.component.interface zope.app.component.metaconfigure zope.app.container.contained zope.app.container.interfaces zope.app.datetimeutils zope.app.event.objectevent zope.app.form.browser.metaconfigure zope.app.form.browser.submit zope.app.form.interfaces zope.app.form.utility zope.app.location zope.app.location.interfaces zope.app.pagetemplate.viewpagetemplatefile zope.app.publisher.browser.globalbrowsermenuservice zope.app.publisher.browser.metadirectives zope.app.publisher.browser.resources zope.app.publisher.browser.viewmeta zope.app.publisher.fileresource zope.app.publisher.pagetemplateresource zope.app.security.interfaces zope.app.traversing.adapters zope.app.traversing.browser.interfaces zope.app.traversing.interfaces zope.component zope.component.factory zope.component.interfaces zope.component.servicenames zope.configuration zope.configuration.exceptions zope.configuration.fields zope.event zope.exceptions zope.interface zope.interface.common.mapping zope.interface.interface zope.interface.interfaces zope.publisher.interfaces.browser zope.schema zope.security.checker zope.security.management zope.tales.pythonexpr
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
P.S. We definately want zope.testing too. I'm surprised that Five isn't using it.
Well, I didn't grep the tests directory. ;) I'm leaning more towards realeasing 2,8 now, and skipping this renaming thing alltogether. But then, I don't know your reason for wanting to do it in Zope 2.8, which I expect is a really good one (it usually is). -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro wrote:
Jim Fulton wrote:
P.S. We definately want zope.testing too. I'm surprised that Five isn't using it.
Well, I didn't grep the tests directory. ;)
I'm leaning more towards realeasing 2,8 now, and skipping this renaming thing alltogether. But then, I don't know your reason for wanting to do it in Zope 2.8, which I expect is a really good one (it usually is).
I want zope.interface and zope.testing. I'm willing to include other things as long as it doesn't require more than an "svn cp" and if people will find it useful. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Lennart Regebro wrote: [snip]
I'm leaning more towards realeasing 2,8 now, and skipping this renaming thing alltogether. But then, I don't know your reason for wanting to do it in Zope 2.8, which I expect is a really good one (it usually is).
I want zope.interface and zope.testing.
I'm willing to include other things as long as it doesn't require more than an "svn cp" and if people will find it useful.
As little as possible would be preferable in that case, I think. The more is included, the more likely there's version skew. Regards, Martijn
Jim Fulton wrote:
Would it make sense to have Zope 2.8 include all of the packages below other than zope.app and for Five to supply it's own zope.app?
It would make life harder for Five, and create more work for us, as we'd have to worry about: * shipping a zope.app ourselves (does it contain binaries? will it ever contain binaries? Right now we can just lift along ZopeX3 releases) * we'd have to worry about version skew. Suddenly we're locked into whatever versions of the Zope 3 code is in Zope 2.8 and whatever version of zope.app that works with that version. Right now Five is completely free to track ZopeX3 releases and there is no worry about version skew. If there is a knob to turn off anything Zope 2.8 ships then life would be a bit harder for people installing Five, as it'd need an extra zope.conf switch besides the path to Zope 3 that already needs to be there. It's doable to document this though. As to Five, this whole exercise, no matter what packages are copied, only makes life harder, not easier. I was looking to go this way (including more zope 3 stuff into zope 2) a year ago, and decided I couldn't make progress that way, as I had to wait for all kinds of things I couldn't control easily, like Zope 2.8 and the Zope 2+3 interface compatibility package. Then I got to liberate zope.interface from the one incompatibility that really prevented Five. After that, Five was ready to be freely developed, independent of the unpredictability of Zope 2 *or* Zope 3 releases. Any addition of Zope 3 code to Zope 2 will make life harder there. I understand that for a future version of Zope 2, Zope 3 code will be included. I understand one direct use case is some Zope 3 persistence system that can be used to help with ZClasses. I understand one other set of use cases is to make it possible to start using Zope 3 technology in Zope 2 (this use case could also be fulfilled by something like Five). I can also see an ease of deployment use case -- no huge Zope 3 package to download and install separately. Then again, such a separation between the projects does make life easier sometimes, as is evidenced by the trouble Five would get in with more mixing. What other use cases are floating around? I cannot judge how likely version skew is between zope.app and the parts of the zope package that will be in Zope 2.8. Anyway, more work for Five developers doesn't mean this shouldn't happen, but perhaps a review of the use cases driving this would be helpful. If it's really only about making ZClasses work in Zope 2.8, is this really the only way forward? If not, I'd prefer to stick to the original plan, and wait for Zope 2.9 before Zope 3 integration starts to happen. Regards, Martijn
Martijn Faassen wrote:
Anyway, more work for Five developers doesn't mean this shouldn't happen, but perhaps a review of the use cases driving this would be helpful. If it's really only about making ZClasses work in Zope 2.8, is this really the only way forward? If not, I'd prefer to stick to the original plan, and wait for Zope 2.9 before Zope 3 integration starts to happen.
I agree. Get Zope 2.8 out now and then we can work on the Z3 integration in 2.9, preferrably merging Five into 2.9 completely. That integration should be rather easy, as Five is already in a workable state, and it's mostly a case of making copy zope.* to Zope2. Or am I missing something? (The renaming Jim did is fine, of course). -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
--On Mittwoch, 2. Februar 2005 19:28 Uhr +0100 Lennart Regebro <regebro@nuxeo.com> wrote:
I agree. Get Zope 2.8 out now and then we can work on the Z3 integration in 2.9, preferrably merging Five into 2.9 completely. That integration should be rather easy, as Five is already in a workable state, and it's mostly a case of making copy zope.* to Zope2. Or am I missing something?
+1 to defer the integration of Z3 technologies until 2.9. It would be nice to have this stuff in Z2 soon but the more important thing is to get a reasonable and stable 2.8 asap because people are waiting for MVCC which is a very important feature - more important than providing than built-in support for Five (which can be added manually by people interested working with Five). -aj
Martijn Faassen wrote at 2005-2-2 19:09 +0100:
... What other use cases are floating around?
The CMF user group would like to use Zope3's events and subscriptions to make creation, deletion and modification interception more flexible. Me, too, I am very interested in object creation/deletion/modification events for a loose coupled architecture involving content, associations, workflow -- all interfacing with one another via the above mentioned events. -- Dieter
Dieter Maurer wrote:
Martijn Faassen wrote at 2005-2-2 19:09 +0100:
... What other use cases are floating around?
The CMF user group would like to use Zope3's events and subscriptions to make creation, deletion and modification interception more flexible.
Yes, those are definitely useful. I mean, I don't doubt there are use cases for something like Five, I'm talking about use cases for moving Zope 3 packages into Zope 2. Presumably you'd like to be able to subscribe to events and the like, so does that mean Zope 2 needs ZCML too? You quickly get very close to Five territory then.
Me, too, I am very interested in object creation/deletion/modification events for a loose coupled architecture involving content, associations, workflow -- all interfacing with one another via the above mentioned events.
Part of the Zope 3 event story is actually already implemented in Five, though not tested a lot as far as I know. Regards, Martijn
participants (12)
-
Andreas Jung -
Chris Withers -
Christian Heimes -
Dieter Maurer -
Fred Drake -
Jim Fulton -
Lennart Regebro -
Martijn Faassen -
Paul Winkler -
Rodrigo Dias Arruda Senra -
Sidnei da Silva -
Stephan Richter