[Grok-dev] ZTK and zopeapp

[Martijn Faassen]

Paul Wilson wrote:
> 2009/12/30 Souheil CHELFOUH <trollfot at gmail.com>:
>> I would love to be able to ditch zope.app out of grok. This can be
>> used by extensions libraries, but, Grok itself has no reason to use
>> it, according to me.
>> We need, of course, to provide alternatives, especially for advanced
>> features, like authentication, etc.
>> In Dolmen, I try to avoid the use of zope.app also. I'm not sure what
>> needs to be done for Grok 1.1 though.
>> What decision is needed ? What do we need to do ?
> 
> Can someone explain what's wrong with zope.app.*. I know people are
> going to great lengths to remove it... but why? What's the history?

I'll try to give a sketch of what's going on:

When Zope 3 developed, we had a general rule that was something like this:

* zope.* will contain packages that are more generally reusable in other 
Python projects.

* zope.app.* will contain things specific to Zope 3 "the application 
server", which was to be the equivalent of the Zope 2 app server. I.e. 
it can be started, has a specific configuration, includes a user 
interface (the Zope 3 ZMI).

It was hard to strictly follow this rule as it wasn't always easy to 
figure out what went were. Over time we also relaxed the rule and zope.* 
started to contain code that did depend on more publisher-specific stuff 
in zope.app, like zope.formlib.

Until 2007, all these packages were developed and tested together. This 
meant that all packages within Zope 3 could easily depend on each other 
in all kinds of different ways.

In 2007, we exploded Zope 3 into separately distributed libraries. The 
advantage of that is that these libraries can more easily be 
independently reused, and that we can more easily provide updates to 
specific libraries without having to update all of them at the same time.

Another advantage of the "explosion" is that it made the dependency 
structures between our packages clearer. It turned out that most 
packages, also those intended to be reusable, would pull in almost all 
other packages if you depended on them, through a complex dependency 
relationship. That makes such packages less than reusable, and hard to 
understand ("why does it need 50 packages just to do forms?"). It's also 
a potential security risk to ship a lot of code that you don't really 
need but that is still there and activated. And a performance drain on 
startup loading all that ZCML.

The community also had more or less given up on the Zope 3 ZMI at the 
time; nobody as really using it. Still we were including lots of code 
that supplies the ZMI, and some content objects that never really took 
off, such as, say, ZPTPage.

The role of the Zope libraries had also changed since it started: Zope 3 
is not used only as an application framework, but also as part of other 
systems, such as Zope 2 and Grok. Both Zope 2 and Grok have no real use 
for the ZMI at all.

So now Zope 2 and Grok were shipping with a ton of code that wasn't 
really used by these systems.

Early 2009, some things happened to reflect this changed role:

* we decided to refocus our efforts from the big Zope 3 to the libraries 
we all share, the Zope Toolkit. Zope 3 is just one user of the Zope Toolkit.

* we made a huge amount of progress cleaning up dependencies between the 
packages.

One strategy to clean up dependencies has been to mine zope.app.* for 
code that is more reusable, leaving old stuff like the ZMI behind in 
zope.app.* (zope.container versus zope.app.container is one such 
example. zope.app.container only contains ZMI stuff now).

So now "zope.app.*" is seen as a whole lot of old stuff that we don't 
really need for Grok. If we can make Grok not use all the zope.app.* 
stuff anymore, Grok will have a *lot* fewer dependencies. The 
dependencies that we do have will have a clearer role. We can stop 
worrying about all that code that we mostly weren't using in the first 
place, and worry better about the code that we *do* use.

I'm not saying that nothing useful is left in zope.app.*: zope.app.form 
is an example that we use if we use zope.formlib. There is probably 
other stuff. We'll find out as we try to make Grok use less of 
zope.app.*. We'll need to decide on a case-by-case basis whether we want 
to salvage code from zope.app.* or whether we can cut the dependency 
altogether.

Does that help?

Regards,

Martijn