[Zope-dev] the Zope Framework project

[Chris McDonough]

Martijn Faassen wrote:
> Hi there,
> 
> Chris McDonough wrote:
>> Martijn Faassen wrote:
>>> Martin Aspeli wrote:
>>> [snip]
>>>> You and I had a discussion a while back about forking the zope.component 
>>>> ZCML directives, and how it would've been better to work within the 
>>>> boundaries of the Zope packages so that everyone who wanted to lose the 
>>>> zope.security dependency could benefit, rather than fork this and all 
>>>> other configuration that depends on the core ZCML directives. 
>> As I remember it, you scolded me about doing it, then when I did it anyway, it
>> worked its way over to the Grok list, where any alternate idea other than a
>> plain fork died on the vine.  That's what I figured was going to happen, so I'm
>> glad I actually took action.
> 
> Huh? 

Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen.

> We need a refactored zope.component for the Grok project as well. 
> Why did it die on the vine? Perhaps if someone had been integrating 
> these experiences and requirements properly on zope-dev it'd have 
> transformed into positive improvements in zope.component itself by now.

AFACIT, you (meaning Faassen) wanted to focus on lower-hanging fruit at the
time: http://mail.zope.org/pipermail/grok-dev/2008-December/006946.html  (which
I believe was totally reasonable).

> [snip]
>> Frankly, I don't care that I had to create alternative ZCML directives.  This
>> was, and is, and always will have been, the right thing to do.  In fact, the
>> only thing preventing Grok or anyone else from using the stuff created out of
>> that effort wholesale (repoze.zcml) is the *brand*. 
> 
> That's incorrect. We already have an implementation of alternate 
> directive (aka grokkers) to register the zope.component components in 
> grokcore.component, and have had them for much longer than you did.
> 
> Adding a *third* way to configure components, i.e. repoze.zcml, to the 
> mix is hardly going to improve matters for Grok. It's useless anyway as 
> we need to support the zope.component[ZCML] way anyway for ZCML, and 
> support grokcore.component for code that does it the Grok way.

I also mentioned "or anyone else" above; the point is just to reduce
inappropriate dependencies.  Inappropriate dependencies still remain in
zope.component's implementation of these ZCML directives.  These inappropriate
dependencies are shed when you want ZCML and you use repoze.zcml.  Fine, Grok
may not need it because it just doesn't care about ZCML at all; but other people
who want to use ZCML without the other kitchen sinkness do.

> I'd rather have one underlying action API that did the minimal but right 
> thing in zope.component that grokcore.component and repoze.zcml and the 
> Zope Framework (with its additional requirements for security) can all 
> build on.

Why does it *have* to be in zope.component?  What magic does this name imply?

> Switching over to repoze.zcml would only gain Grok *more* code and a 
> harder to comprehend situation.

Maybe *Grok* doesn't need it, but given that an application needs some ZCML to
kick off the loading of components, and given that this ZCML needs to include
one of the "utility", "adapter" or "subscriber" directives, *eventually* you
could ditch zope.security, zope.location, zope.publisher, zope.traversing,
zope.i18n, and pytz by using repoze.zcml directives instead of the ones built in
to zope.component.

Here's an example of a non-Zope application that might make use of such a
package:  http://plope.com/Members/chrism/pluginizing_an_app

> And you think it's all due to the brand...

Yes!  Someone who *wants* to use basic ZCML directives but doesn't want
zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and
pytz can *already* use repoze.zcml; the only thing they don't get here is the brand.

Why should we punish the folks who are already using the zope.component
directives with security in them by changing them in order to service some goal
of fidelity with brand?  Who cares what it's called?

>> I don't care about
>> Zope-the-brand anymore, I just care about Zope-the-technologies.  Why would the
>> fact that this more reasonable set of directives is not named Zope anymore
>> matter?  What about that whole situation was not a win?
> 
> I already spelled out the above on the grok-dev mailing list before, but 
> you didn't seem to pick up on my explanation.

I guess not.

>>> When I brought up the issue of trying to improve zope.component 
>>> recently, I got a lot of divergent feedback and nothing happened. It'd 
>>> be nice if instead such energy instead resulted in a concrete set of 
>>> actions.
>> I didn't participate because I had already scratched that particular itch.  I
>> created something that *everyone* can use; it might not be named Zope, so be it.
> 
> I pointed out above why it'd be not very useful for Grok to use it. In 
> fact you created something that is redundant if you use the rest of the 
> Zope Framework as well (or even just zope.component[zcml]). It isn't 
> something that *everybody* can use just like that.

I don't know what's so hard to understand about this: not everyone wants to use
the ~78 packages that currently make up "the Zope framework".  This is the
entire point of what I'm saying.  Very few people will never care about "the
Zope Framework" in entirety, if it's defined as you define it above.

99% of people in the Python community *dont use anything related to Zope* and
*WILL NEVER USE ANYTHING FROM IT IF IT'S ALWAYS A BALL OF 78, 60, OR EVEN 10
PACKAGES*.  If you're defining "everyone" in your sentence above as "everyone
who already uses Zope", I believe that is incredibly short sighted.  We could do
so much more if we ditched the notion that the big glob of packages you're
trying to recast as "The Zope Framework" is of more value as a glob than as
individual packages that any Python programmer could use.

> Forking is one way to solve the problem and forget about it, if you 
> don't care about compatibility with the Zope Framework. That's fine. 
> It's something you have the freedom to do of course and undoubtedly you 
> are much happier with it. It's also unfortunate for me, as your 
> improvements are not making in into the shared component.

But... but... you can already use this stuff.  How does that not help you?  It
just doesn't have the Zope name.  But it's already perfectly usable both inside
and outside The Zope Framework (see repoze.catalog, repoze.session,
repoze.zodbconn, repoze.who, repoze.tm2, repoze.sendmail, repoze.retry,
repoze.errorlog, repoze.evolution, repoze.folder, repoze.debug).  If you really
believe what you say above, you are *choosing* to not use it until it has a Zope
brand attached to it.  The entire *point* of this stuff is that it's possible to
use it both outside a Zope application server *and* within it.  It may not be
compatible with some *old* implementation, but that doesn't make it *unusable*.

We could do the same for new Zope packages and get a lot more traction without
dragging all 78 packages behind us as we move forward.

> So while the problem is solved for you, it isn't solved for me. Grok has 
> different goals concerning compatibility with the Zope Framework, and 
> therefore more interest in improving the underlying framework itself.

Improvement of "the framework" does not always need to take the narrow shape of
changing the code inside Zope's SVN or coming up with a new zope.* package.

> These are different philosophies. You with your philosophy should have 
> no problem with me trying to improve the framework experience though, as 
> you can go off on your own anyway and cooperate on bits of it whenever 
> you want. So I find it frustrating to hear you say "no" so much now

I have no faith whatsoever that staying on the course we've been on for the last
9 years (large interconnected codebase, backwards compatibility at all costs,
lack of any consumable documentation at a package level, not much curiosity
about how other Python web frameworks work, not much real cooperation with folks
that maintain other Python web frameworks, a constitutional inability to attract
new users) will bring any sort of positive change.  I see the canonization of
"The Zope Framework" as a big ball of interconnected code a continuation of this
pattern.  We could do so much more if we just decided to become a part of the
larger Python world by decentralizing.  But c'est la vie.

> It's fine if you don't care about the "Zope" brand anymore, but I'm 
> still allowed to care about it, right?

Of course.

- C