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