[Zope-dev] who wants to maintain Zope 3?
Jim Fulton
jim at zope.com
Tue Apr 14 11:56:55 EDT 2009
On Apr 14, 2009, at 11:20 AM, Martijn Faassen wrote:
> Hey,
>
> Jim Fulton wrote:
>
>> What the heck is the "Zope Toolkit"? Is there a page somewhere that
>> defines what it is?
>
> http://docs.zope.org/zopetoolkit/about/index.html
>
>> I thought Zope 3 was being renamed "Zope
>> Toolkit", but given recent discussions, I'm not sure.
>
> That never was the idea. The idea was to separate the concept of the
> toolkit from the concept of "Zope 3". Zope 3 (if people want to
> maintain
> it) is a user of the Zope Toolkit just like the other users. The Zope
> Toolkit inherits its libraries from Zope 3 but is trying to take on a
> lot less code.
>
> The goal is to take on *less* of a burden to maintain than the full
> Zope
> 3, and to move a bit faster than we have been.
>
> The Zope Toolkit is a project that:
>
> * aims at maintaining and releasing the various Zope libraries
>
> * aims at supporting the projects that some of use these libraries
> individually (repoze, bfg, twisted)
>
> * aims at supporting the projects that use most of these libraries
> as a
> set (Grok, Zope 2, Zope 3).
>
> * doesn't include the ZMI bits
I don't think these "bits" are cleanly separated. For example, if a
content component has some views, are those ZMI bits?
Can you identify projects that are in or out of the toolkit? What
about zope.publisher? zope.security? zope.app.publication?
> * won't have a way to install it (but Grok and Zope 2 and Zope 3 might
> come to share a large part of the installation method)
>
> * will try to shrink the codebase as much as it will try to grow it.
> To
> this effect the refactoring efforts, with the aim to throw out
> libraries
> (from the toolkit, not from the universe of packages) quite
> aggressively. Hopefully much of zope.app.* can go, as the useful non-
> ZMI
> bits get salvaged.
>
> The Zope Toolkit is *not* like Zope 3 in an important sense: there's
> no
> attempt to provide information about how to install it and start
> developing with it. We'll have this information for the individual
> libraries in the tookit, and for Zope 2 and Grok and so on, but not
> for
> the Zope Toolkit itself.
I agree with the idea of simply supporting a library of components.
I'm uncomfortable with the idea of saying you're going to "shrink the
codebase" without saying what's going. I don't want to see a separate
"Zope 3 " project distinct from the "Zope Toolkit". I do want to see
the components we're using live within a project. If the "Zope
Toolkit" doesn't include components in common use, then I don't think
it has a lot of value.
Jim
--
Jim Fulton
Zope Corporation
More information about the Zope-Dev
mailing list