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