Advocating the splitting of Zope in subpackages
On Thu, May 11, 2000 at 01:01:40AM -0500, Roman Milner wrote:
Hello. I'm trying to use the ZODB and Catalog out side of zope...
Folks, it's about time (or past time) Zope is splitted from its monolithical package into the real packages it uses. I'm facing similar problems when using ZPublisher.Client in gnope. These things should IMHO be distributed as independent Python packages, at least: - ZODB - Catalog - ZPublisher - StructuredText They were all designed to be Zope-independent (ok, the only good reason to use ZPublisher outside Zope is for clients, but anyway, it's designed to make other things possible). I'm sure there are more. What would be the drawbacks of making these subpackages independent? Management? I don't think that would be too bad. And the possibility of having them released independently is also a very big bonus (StructuredText is _so_ unmaintained that there are people working on an independent version - and it looks cool!) []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://www.webcom.com/lalo mailto:lalo@hackandroll.org pgp key in the personal page Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
Lalo Martins wrote:
These things should IMHO be distributed as independent Python packages, at least:
- ZODB - Catalog - ZPublisher - StructuredText
I'd add Transaction Manager to the list. Right now it's merged with ZODB, so it's hard to figure out how it works, and some parts are in peculiar places such as Shared.DC.ZRDB. -- Itamar S.T. itamar@maxnm.com
On Thu, 11 May 2000, Lalo Martins wrote:
These things should IMHO be distributed as independent Python packages, at least:
- ZODB - Catalog - ZPublisher - StructuredText
It used be that they were independent. Even DTML was. I have kept the old code!
They were all designed to be Zope-independent (ok, the only good reason to use ZPublisher outside Zope is for clients, but anyway, it's designed to make other things possible).
Noooo ZPublisher+ZServer is great to quickly publish python modules. I use it all the time. This is how simple it is: bobo_application=<YourClass>() And then run ZServer pointing it to your module!! All the methods in your module (as long as they have strings) are immediately available through the web in a manner similar to Zope. The whole Zope is actually such an app. For many apps Zope is a big overkill, especially when you don't want to store instances in a ODB or provide through the Web editing/security etc. Most of the independancy was broken when the special regular expression module was intoduced to deal with threads. At least this is what I have observed trying to split a few things from Zope. pavlos
Lalo Martins writes:
Folks, it's about time (or past time) Zope is splitted from its monolithical package into the real packages it uses. I'm facing similar problems when using ZPublisher.Client in gnope.
Agreed; we're beginning to use the ZODB to store data outside of Zope, and getting just the minimal set of dependencies is a pain. I ran into the same problem for the earlier Oedipus versions that used the ZODB, and my instructions simply told people to install Zope and add lib/python to their path. While completely packagizing Zope is a big job, it does seem possible to take it in little increments, and splitting out some of the more useful components would be a start. -- A.M. Kuchling http://starship.python.net/crew/amk/ What on earth is less likely than *two* committees to produce a seamless web of anything but intrigue and deficit? Who said "three committees"? -- Stan Kelly-Bootle, _The Computer Contradictionary_
Andrew M. Kuchling wrote:
Lalo Martins writes:
Folks, it's about time (or past time) Zope is splitted from its monolithical package into the real packages it uses. I'm facing similar problems when using ZPublisher.Client in gnope.
Agreed. [snip] While completely packagizing Zope is a big job, it does seem possible to take it in little increments, and splitting out some of the more useful components would be a start.
My 'aye' added to the chorus. Some advantages: * it's the Right Thing To Do (can help cleaning up the code). * could help elucidate some interfaces more clearly. * the sub packages can also be open-source developed by the people who don't need Zope but want to use the sub package in isolation. They will probably exercise other parts of the code and may find problems and interesting new features to add that Zope-users won't. This will on the long term also be better for Zope as a whole. * clear modularization will probably also aid in the understanding of Zope as a whole, as each component can be studied in isolation. * you can more easily swap out a component for a new one. * it's more easy to write automated test suites for the isolated packages. Of course, Digital Creations is already aware of these things; Zope is already heavily modular. We run the danger now though that things will start to merge together into a mess, so being explicit about packaging the components could help a lot here. Perhaps we should start a Zope SubPackages Wiki and discuss this further? People can rip various packages out of Zope and test them in isolation, and we can then offer them as downloadables on the Zope site. The Wiki can serve as a pointer to the various packages out there. Regards, Martijn
participants (5)
-
Andrew M. Kuchling -
Itamar Shtull-Trauring -
Lalo Martins -
Martijn Faassen -
Pavlos Christoforou