[Zope-dev] Dependencies and future of zope 3

[Chris McDonough]

Stephan Richter wrote:
> On Wednesday 03 September 2008, David Pratt wrote:
>> I am trying to avoid the need for selective forking that Chris has found
>> necessary to make progress with bfg. I want to continue using zope since
>> these things are a big factor for the factors I stated.
> 
> I do not think that this community is so hard headed that forking is 
> necessary. As far as I remember, I have not seen any serious commitment on 
> their side. Many of us are interested in decreasing the dependency tree, so 
> solutions will be found. It is just so much easier to fork.

I'm not sure what "committment" and "their side" implies here, but it's probably
a good idea to explain what "selective fork" refers to in this context.

The package that David referred to as a fork (because I mentioned to him offhand
that it was) was "repoze.catalog" (http://static.repoze.org/catalogdocs/).  This
is a package that is modeled on zope.app.catalog, but which relies on only
zope.index.

In reality, it's maybe less of a fork than it is a reaction to a divergence of
goals.  There's no way I could have gotten what I needed *without* abandoning
any hope of pushing the changes up to zope.app.catalog because it's likely that
nobody but me cares about the use case: zope.app.catalog relies on "the world"
because it wants to hook in tightly with Zope containers, local site managers,
object events and so on.

I didn't want any of that; I just wanted something that I could hand some text
and a docid and have the results queryable later, making the responsibility of
the catalog to later only hand me back a set of docids based on the query
parameters.  It'd be absurd to pull down more than zope.index and ZODB for this
purpose, which is exactly what the repoze.catalog package relies on.

Sometimes such divergences are just necessary.  Take for example, Zope 3, which
was a "fork" of Zope 2 in basically the same way that repoze.catalog is a fork
of zope.app.catalog.

You might argue that it should have retained the "Zope" brand (it hasn't).  But
then again, it's is not really any more a fork than, say, z3c.form is of
zope.formlib, and neither does that.  You could also maybe argue that it should
live in the Zope SVN repository (it doesn't).  But then again, neither does
Plone or hundreds of other derivative projects.

If we unhose the dependency tree a bit, we might be able to avoid "silly" forks
of things, but we'll never be able to mend the divergence of goals and natural
progress.  I'm not terribly optimistic that the existing community has the will
or the time to do the necessary unhosing under the "Zope" flag; it will be
extremely painful and time-consuming, and  a lot of it will imply similar
"forks" which will also need to be maintained even while the old code lives on.
 These forks won't be in the interest of folks who just want to use Zope 2 and
Zope 3 wholesale, which appears to be a solid majority right now given the
reluctance to make changes to existing packages.

- C