[Zope-dev] Stripping down zope.component

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(reposted at Martijn's request in a new thread).


Martijn Faassen wrote:
> Hi there,
>
> Paul Everitt wrote:
> [snip]
>> 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
> users.
>
> 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
> proposal.

OK, can we table the proposal per se for the moment, and "prototype" the
process around the "how do we move zope.component forward" question?
I'm not even sure I understand why you think anything in repoze.zcml has
squat to do with zope.component, but I could just be missing the obvious.

I have a "strawman" proposal, focused on stripping zope.component down
as far as possible:

1. Merge my branch which drops the deferred import stuff.

.. note:
   I'm about to do this merge, based on positive feedback on the list.

2. Move the persistent registry stuff out into another package,
   including whatever support is needed to allow for people to migrate
   existing persistent references.  Effectively, this moves one "extra"
   out to a package, *including* its testing dependencies.

3. Move the ZCML directive implementations out into another package,
   taking the zope.security and zope.configuration dependencies along
   with them.

4. Rework zope.hookable to use a pure-Python implementation via
   descriptors, instead of the C extension.  Make it a non-optional
   dependency (but small and lightweight) of zope.component.  If
   *current* profiling shows that the hooked things are bottlenecks,
   make the C version and optional replacement for the Python version.

.. note:
   In the meanwhile, I have done the latter, with a pure-Python
   'hookable' module in zope.component as a fallback for zope.hookable.

At the end, we would have three packages:

  zope.component
    depends on:
    - zope.interface
    - zope.event
    - zope.hookable (optional)

  zope.componentzcml (BIKESHED NAMING ALERT)
    depends on:
    - zope.configuration
    - zope.security
    - zope.configuration
    - zope.proxy
    - zope.i18nmessageid

  zope.persistentregistry (BIKESHED NAMING ALERT)
    depends on:
    - zope.configuration
    - ZODB3

Folks could then work on refactoring the new packages (e.g., depending
on a separate 'persistent' package, making the secuirity bits optional,
etc.).


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrxQl+gerLs4ltQ4RAgpLAJ0bOowoDHcKmcdolDjoFT+eTisUhACg2Bt0
wZ7SzkMMpBd1Q89z2qilc0Q=
=Kl5M
-----END PGP SIGNATURE-----