Paul Everitt wrote:
> Hopefully the Zope Framework proposal helps untangle this, and gets to a
> point where you don't have to keep the Uberthing in your head when doing
> something small.
It's not small, as it has an impact on a lot of things that build on
zope.component. Changing things low in something that lots of people
have built stacks on is almost never a small change.
Just look at Python 3, which makes a bunch of actually rather small but
still incompatible changes to the language. While small from the
perspective of the language, they're *huge* from the perspective of the
So you need ways to coordinate such changes.
I hope that having someone actually taking responsibility for
zope.component's evolution can get the zope.security dependency out of
it, and then improvements of repoze.zcml into it, or alternatively move
the ZCML implementations *entirely* out of zope.component. I hope Chris
will coordinate with us where necessary.
I don't want security bits to sit around in zope.component either.
grokcore.component doesn't need that code, just like repoze.zcml doesn't
need that code. It's still there, even if you use repoze.zcml, just
inactive. I tried to propose various ways forward. I got nowhere as I
got 10 people giving 10 answers. Original problem unresolved.
I'd like there to be someone who can make this decision and I'd like
this someone to usually make *positive* decisions that work towards
resolving the underlying issue, while coordinating with everybody that
is impacted by this decision.
The zope.component ZCML case was very much in my head as I wrote this
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -