[Zope-dev] the Zope Framework project

[Martin Aspeli]

Tres Seaver wrote:

> It is a nightmare, but not one which a KGS can really fix: sometimes
> your project needs its *own* KGS.  Honestly, the only safe thing for
> anybody trying to support a large application in production is to run
> their own index, and do the gatekeeping of packages into it themselves.

This is true, but not everyone is supporting large packages in 
production. People need a place to start, if nothing else, and when it 
comes time to doing a migration project (!), then you need some other 
known good set to work "backwards" from.

> For instance:
> 
> - - How many projects are there (community efforts, as well as individual
>   sites / applications) need updates to some of the packages
>   traditionally part of a Zope3 release?  I would bet that there are
>   lots of such projects.

Sure. Having individual eggs is a blessing here.

> - - How many projects are there which are going to need a "Zope 3.5"
>   release (as opposed to updates to some of the packages traditionally
>   part of Zope3)?  I would bet that this set is smaller than the first.
>   For instance, I know that Zope 2.12 *says* it will rely on 3.5, but I
>   don't know what that means, actually.  Grok already maintains the
>   moral equivalent of its own KGS, right?

Certainly, people who start out and want to know which packages work 
together. Without something like this, managing dependencies becomes 
very hard. If setuptools is left to pull in whatever it wants, you will 
probably end up with breakage, unfortunately.

> - - How many need *all* of Zope3, including the ZMI?  I'm betting that
>   set is much smaller than either of the others?

Probably none. So having better dependencies would obviously be good. I 
think you still need a KGS of sorts, but you don't need to depend on 
*all* of it. :)

> - - Of the first set, what is the likelihood that different projects
>   will have conflicting goals about the direction of one or more
>   packages?
> 
> Given the likelihood that a monolithic Zope 3.5 release is not
> interesting to lots of the folks who both develop and consume its
> packages, how much coordination is going to be possible (or even useful)
> around the idea of another release?

Maybe we could identify some "vectors" down the dependency graph that we 
*do* care about. If we analysed our projects (Plone, and a bunch of 
add-on products, for instance), we could probably manage to maintain 
KGS' that say "if you want the container interfaces, these packages are 
known to work together".

> Maybe we need to create something more like self-organizing
> mini-communities around the various packages (or maybe sets).

Heh... right. ;-)

>  E.g., I
> would bet that almost everyone active on this list has a stake in
> zope.interface, zope.component, and their dependencies.  Note that *two*
> of the remaining dependencies (zope.deferredimport, zope.deprecation)
> are only there to deal with BBB isssues:  maybe they should go?

Why? They're tiny, and BBB is good. No piece of framework code can be 
taken seriously if it pretends that people are not going to need 
backwards compatibility.

> Another, zope.proxy, is a blocker for using the packages on non-CPython
> platforms:  should it go?  If we consider those packages *in isolation*,
> as things potentially useful outside any larger framework, the answers
> to those questions might be different.

True.

> I'm not so sure that any other package is going to be as widely
> interesting.

I can think of a few: the container stuff, browser views and pages, page 
template files, for example.

>  I also think that having the *whole* Zope community do
> oversight oversee on the rest is less useful than having the folks with
> "skin in the game" for a particular package steer it.  I am unlikely to
> care much about anything in the Z3 ZMI, for instance, or about a number
> of other packages in our various namespaces:  I could do my job better,
> *and* keep from interfering in others' interests (e.g., the "stop
> energy" Chris mentioned), if we separated out the various areas of concerns.

True. However, someone still needs to think about whether these things 
are pulling in the same direction, or becoming incompatible with one 
another.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book