Fabio Tranchitella wrote:
[snip]
 > All the proxying stuff can be made optional with conditional imports.
 > I think the only solution to make zope.security optional without
 > removing the "permission" attribute is to do something like:

 > try:
 >    from zope.security.zcml import Permission
 > except ImportError:
 >    from zope.schema import TextLine as Permission

Thanks for that feedback, that's indeed a good point to bring up.

Time for some conclusions in this thread so that Thomas or someone else 
can proceed if they want to.

* we should move the zope.site.hooks in and make it optionally dependent 
on zope.security (if it's available). I think we should go ahead with 
this now.

* zope.copmonent.zcml has two issues:

   * it needs an [zcml] extra with quite a few extra dependencies that
     are not needed for normal zope.component use

   * it's dependent on zope.security. Fabio for one has a use case
     where this dependency isn't needed, and it'd be simpler if it
     could have all-python dependencies.

To resolve the zope.component.zcml issue, I'm going to redo a proposal I 
did a while ago but ended up in an endless discussion then.

I propose we create a new zope.componentzcml package that contains the 
zope.component.zcml code. This package is *optionally* dependent on 
zope.security as well as zope.proxy. It should work with just a 
dependency on zope.i18nmessageid and zope.configuration. We should 
figure out a way to test out both situations somehow. Ideas?

This will net us:

* a zope.component package with a lot less extra dependencies. Some 
packages that depend now on the dependency-heavy zope.site can now 
depend on zope.component, which should flatten our dependency structure 
quite a bit. It can be used without zope.security being available.

* a zope.componentzcml package. Whenever a package says it needs 
"zope.component [zcml]" we're going to say it needs 
"zope.componentzcml". I think that's a very minor upgrade issue if we 
mark it well in the CHANGES.txt. It can be used without zope.security 
and zope.proxy being available (the goal should be usability without C 
compiled extensions). It can also *not* be used at all and repoze.zcml 
can be used. Such a deployment then won't have the confusing extra 
implementation of ZCML now in zope.component.

Optional dependencies aren't perfect, but I think this would mean a step 
forward so we should go ahead.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to