[Zope-dev] the Zope Framework project

[Martijn Faassen]

Hi there,

Chris, I think you are misunderstanding my position quite
dramatically. Perhaps you should calm down and reconsider what I've
been saying, as I believe we're a lot closer than you seem to think.

On Tue, Mar 3, 2009 at 8:42 PM, Chris McDonough <chrism at plope.com> wrote:
[snip]
>> 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?

It doesn't, but it should then be *removed* from zope.component into
some other package (which could be repoze.zcml for all I care).

I don't want there to be a duplicate implementation laying around and
I'd like there to be a clean dependency structure. At the same time,
directives need to exist that are compatible with the Zope Framework.
It'd be nice if there wasn't a duplicate implementation of their
actions.

[snip]
>> 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.

Yes, why are you explaining this to me? For a year now people could
use grokcore.component, where they could register their objects
without pulling in those dependencies as well, and not having to deal
with a lot of ZCML either.

> 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'm not talking about the fidelity of the brand. If you use
repoze.zcml or grokcore.component today you'll use two implementations
of the actions and in the case of repoze.zcml, two implementations of
the ZCML directives. Granted those are very minimal in
grokcore.component and mostly the registration functions themselves.
But repoze.zcml contains wisdom about certain WSGI situations that
grokcore.component and zope.component don't have.

What I'd like to do is consolidate all that wisdom about how things
should be registered in *one* place (I don't care what it's called,
and it *could* be zope.component or repoze.zcml) and then build
grokcore.component, repoze.zcml and Zope 3 on top of this. That way
they all share the same underlying technique, including your multi-app
support.

It appears to be the coordination overhead required seems to make this
impossible. Even you who should have an interest in not carrying in
the ZCML implementations in zope.component as they're duplicating and
possibly confusing users of repoze.zcml seem not to agree that it'd be
nicer.

[snip]
> 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.

I'm talking about zope.component here, and you don't seem to want to
change that either. I'm trying to see the big picture of the different
users of this package and think about ways to arrange it so that it'd
be better. Less redundant code, more shared code. You don't seem to be
interested in that, because to you the problem is already solved. I
understand that, but I also don't understand your resistance.

> 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.

Please don't yell at me. I don't take the position that you think I
am. You're telling me things I already agree with.

Why do you think I care so much about clean dependencies in the Zope
Framework? Because I want people to be able to enter the Zope
Framework at any point in the tree. People who don't care about the
rest. Because I want the tree to be simpler so that Grok uses less of
it and I can understand more of it. But that takes coordinated effort
as we do have people using the entire tree and we don't want to leave
those with a broken system.

I'm taking both perspectives at the same time. I don't think they're
mutually incompatible.

You're doing this thing called Repoze. That's a lot of packages and
presumably they share a few philosophies and you make sure they tend
to work together. At the same time people can pick up on individual
packages.

Why can't we have something called the Zope Framework that does the
same for Zope packages?

Do you really think we should forget about any backwards compatibility
and all move over to repoze packages today? I'm not quite sure what
you expect here.

>> 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*.

Why do you think I've said these are unusuable?

Please cut out this whole set of allegations concerning brand. Grok is
using the Zope implementations because we've been using these
implementations for years now and we can't just replace with something
new just like that. I also prefer to invest my time in improving the
original implementations to make progress, but I'm quite open to
putting in new implementations over time if they prove better and
there's a backwards compatible path forward. I think the Zope
Framework should also be open to such decisions to include Repoze
components and use other implementations, though there are some
community and legal hurdles to be cleared.

I might of course lose hope in the ability of the Zope developers to
get organized and produce something that I think is a long-term good
foundation for Grok. In that case breaking backwards compatibility
might be the best step forward, but it'd mean an enormous loss to me
of components I'm already using in various applications I'm
maintaining. I haven't given up hope in the Zope developers yet
though, so I'm doing my best to improve the situation.

> 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.

I have a lot of code that needs to work. I'm doing the best I can in
trying to improve the code that we already have so we don't have to
pull in all 78 packages or whoever many they are. I hope eventually
more of the grokcore.* libraries besides grokcore.component won't have
to pull in the full set, but we aren't there yet. I'd like there to be
a community that is capable of making such changes and other ones.

>> 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.

I think there's sufficient evidence that I'm aware of this, though I
must say I'm happy enough working in Zope's SVN. Sometimes Zope
packages need to be improved, and what's the problem with coordinating
that effort?

>> 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.

I'm very bad about communicating my proposal if you think that's what
I've been proposing or if that is my position. I think you should know
better given my actions. I am really scratching my head that a
proposal that is aimed to make *more* of these packages available to
you on a package level without pulling in a whole set of unrelated
dependencies gets all this resistance from you. Right now we are
maintaining something called Zope 3 and it doesn't know whether it's
an app server with a UI or a set of related packages that build on
each other. I'm simply proposing we recognize that we also maintain
this set of related packages.

Regards,

Martijn