zope.site.hooks is a rather light-weight module that is concerned with the concept of a current site, where the notion of a site is used in the same sense as in zope.component, which actually prefers to only talk about a component registry. In contrast, the rest of zope.site deals with local site managers and container stuff including the implementation of folders. IMO it would be interesting to have the concept of the current site available separately from the rest of zope.site with its 30 dependencies. (For example, zope.browserresource demonstrates how with the present zope.site the need to know the current site in order to determine a URL leads to a dependency on the ZODB.) I would propose moving zope.site.hooks to zope.component.hooks if it wasn't for its use of zope.security in order to remove security proxies in two places. These places have rather old comments that suggest reconsidering the handling of security proxies at some point. Right now, the code that removes the proxies is needed but I'd like to raise the question whether we should try to get rid of it. If there's no objection to this goal, I'd like to investigate what it would take. (Even if zope.site.hooks were to remain a part of zope.site, this would rid zope.site of the dependency on zope.security and at least one other package.) -- Thomas
Hey, Thomas Lotze wrote:
zope.site.hooks is a rather light-weight module that is concerned with the concept of a current site, where the notion of a site is used in the same sense as in zope.component, which actually prefers to only talk about a component registry. In contrast, the rest of zope.site deals with local site managers and container stuff including the implementation of folders.
IMO it would be interesting to have the concept of the current site available separately from the rest of zope.site with its 30 dependencies. (For example, zope.browserresource demonstrates how with the present zope.site the need to know the current site in order to determine a URL leads to a dependency on the ZODB.)
+100 if this makes site-aware code have less dependencies. One can really get rid of a *lot* of dependencies this way.
I would propose moving zope.site.hooks to zope.component.hooks if it wasn't for its use of zope.security in order to remove security proxies in two places. These places have rather old comments that suggest reconsidering the handling of security proxies at some point. Right now, the code that removes the proxies is needed but I'd like to raise the question whether we should try to get rid of it. If there's no objection to this goal, I'd like to investigate what it would take.
We could investigate two options: * just removing that code that remove proxies and sees what happens to significant Zope 3 code bases. Risky. * alternatively, putting in an optional dependency on zope.security in zope.component. If zope.security proxy is importable, try removing the proxies, otherwise don't. Regards, Martijn
Martijn Faassen wrote:
We could investigate two options:
* just removing that code that remove proxies and sees what happens to significant Zope 3 code bases. Risky.
* alternatively, putting in an optional dependency on zope.security in zope.component. If zope.security proxy is importable, try removing the proxies, otherwise don't.
Please don't add new dependencies to zope.component. Even optional ones, IMHO. It makes it harder to re-use for others and more complex to understand. Many people (e.g. those wanting to use GAE) object to the C stuff in zope.security in particular. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Hi On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
Martijn Faassen wrote:
Please don't add new dependencies to zope.component. Even optional ones, IMHO. It makes it harder to re-use for others and more complex to understand. Many people (e.g. those wanting to use GAE) object to the C stuff in zope.security in particular.
Big +10000 I am using repoze.bfg on app engine (and in the past a minimal zope3 stack) and getting rid of zope.security dependancies (and/or gutting it) in other packages is not easy and would hate see it turn up in zope.component. T
Martin
-- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________ 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 )
Tim Hoffman wrote:
On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
Martijn Faassen wrote:
Please don't add new dependencies to zope.component. Even optional ones, IMHO. It makes it harder to re-use for others and more complex to understand. Many people (e.g. those wanting to use GAE) object to the C stuff in zope.security in particular.
Big +10000
I am using repoze.bfg on app engine (and in the past a minimal zope3 stack) and getting rid of zope.security dependancies (and/or gutting it) in other packages is not easy and would hate see it turn up in zope.component.
This would be an entirely optional dependency. The code would work without zope.security being available, just takes zope.security into account when it's there. Note that the 'zcml' extra already depends on 'zope.security'. I'm not exactly happy with that though - perhaps it'd be better if it also was an optional dependency? Regards, Martijn
Martijn Faassen wrote:
Thomas Lotze wrote:
IMO it would be interesting to have the concept of the current site available separately from the rest of zope.site with its 30 dependencies. (For example, zope.browserresource demonstrates how with the present zope.site the need to know the current site in order to determine a URL leads to a dependency on the ZODB.)
+100 if this makes site-aware code have less dependencies. One can really get rid of a *lot* of dependencies this way.
That's what I thought ;o)
We could investigate two options:
* just removing that code that remove proxies and sees what happens to significant Zope 3 code bases. Risky.
To begin with, compat-tests of a number of ZTK packages and a lot of the packages under review for the ZTK fail if I do that. This is why I said the code is currently needed. Typically, this has to do with something about interactions not being available to code like zope.component.subscribers().
* alternatively, putting in an optional dependency on zope.security in zope.component. If zope.security proxy is importable, try removing the proxies, otherwise don't.
I thought about that one briefly, but I don't like it because it introduces at least some knowledge about the security concept to zope.component. While I can't follow why others consider an optional dependency bad from a technical point of view such as usability on GAE, I think zope.component is so low-level that we should value its conceptual clarity greatly. -- Thomas
Thomas Lotze wrote:
I thought about that one briefly, but I don't like it because it introduces at least some knowledge about the security concept to zope.component.
The more I think about it, the less evil this appears to me, though. After all, the zope.component.zcml module has been dependent on zope.security all along (requiring one to install zope.component [zcml] which pulls in zope.security if one wanted to use it). I think I'd be willing to use zope.security optionally for the site stuff provided that we can get the GAE users to agree and with the intention of cleaning up things later according to those old comments in the code which I mentioned previously. -- Thomas
GAE users and repoze.bfg users as repoze.bfg doesn't use zope.security at all
I did a quick grep and it appears that repoze.bfg never actually loads zope.component.zcml so I think if the only dependancies you introduce are via zcml then you should be ok. And given I am running repoze.bfg on app engine it would seem to confirm this ;-) T On Wed, Oct 7, 2009 at 2:57 PM, Thomas Lotze <tl@gocept.com> wrote:
Thomas Lotze wrote:
I thought about that one briefly, but I don't like it because it introduces at least some knowledge about the security concept to zope.component.
The more I think about it, the less evil this appears to me, though. After all, the zope.component.zcml module has been dependent on zope.security all along (requiring one to install zope.component [zcml] which pulls in zope.security if one wanted to use it). I think I'd be willing to use zope.security optionally for the site stuff provided that we can get the GAE users to agree and with the intention of cleaning up things later according to those old comments in the code which I mentioned previously.
-- Thomas
_______________________________________________ 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 )
Tim Hoffman wrote:
GAE users and repoze.bfg users as repoze.bfg doesn't use zope.security at all
I did a quick grep and it appears that repoze.bfg never actually loads zope.component.zcml so I think if the only dependancies you introduce are via zcml then you should be ok. And given I am running repoze.bfg on app engine it would seem to confirm this ;-)
To clarify: We're considering the addition of a module that wouldn't have anything to do with the zcml extra but would talk about zope.security nontheless. Only it wouldn't be a dependency declared in setup.py or in the sense that things would break without zope.security. We'd rather try to import it and if it isn't there, just not do one or two things in the code on the grounds that they'd be irrelevant in that case anyway. As we're thus not requiring zope.security to be installed, I think you should be fine on GAE. I mentioned the zcml extra only because that's how zope.component has to do with the security concept already, as a motivation of why I'm letting go of my opposition to introducing more of that concept into zope.component. -- Thomas
Hey, Thomas Lotze wrote: [snip]
I mentioned the zcml extra only because that's how zope.component has to do with the security concept already, as a motivation of why I'm letting go of my opposition to introducing more of that concept into zope.component.
I think it would be interesting to review zope.component.zcml and see how it depends on security, and see whether we cannot make the dependency optional too. After all, most of what zope.component.zcml does has to do with registration, not primarily security. We could have it bail out with an error if a security-related directive attribute was provided when no zope.security is available. Perhaps all the security-related code that zope.component needs to know about could go into a zope.component.security module that the rest of zope.component can import from if needed. This would then do the ImportError check and install dummy functions if zope.security isn't available (or possibly functions that raise the aforementioned exception). Regards, Martijn
* 2009-10-07 22:40, Martijn Faassen wrote:
I think it would be interesting to review zope.component.zcml and see how it depends on security, and see whether we cannot make the dependency optional too.
I fully agree with this, and the main reason why I use a package like repoze.zcml is to get rid of the (unnecessary) dependency on zope.security. The only problem with making the dependency on zope.security optional is related to the "permission" attribute in the zope.component ZCML directives, which is a zope.security.zcml.Permission. 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 Do anybody else has better ideas? Thanks, Fabio
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
* 2009-10-09 13:59, Martijn Faassen wrote:
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?
zope.component's dependencies are: install_requires=['setuptools', 'zope.interface', 'zope.event', ], The extra dependencies are: extras_require = dict( hook = ['zope.hookable'], persistentregistry = ['ZODB3'], zcml = ['zope.configuration', 'zope.security', 'zope.proxy', 'zope.i18nmessageid', ], test = ['ZODB3', 'zope.testing', 'zope.hookable', 'zope.location', ], docs = ['z3c.recipe.sphinxdoc'], ), Considering that we are not really getting rid of all the extras, instead of creating a new package I'd rather make the dependency on zope.security and zope.proxy optional in zope.component: it is possible to do it with conditional imports, and we are not breaking any application already depending on zope.component[zcml], unless they need zope.security but they are not directly depending on it (which is bad and wrong, in any case). Note that we are already using conditional imports in zope.component._api. Anyway, I'm fine with what Martijn proposed if nobody else supports my idea. Best regards, Fabio
Fabio Tranchitella wrote: [snip]
Anyway, I'm fine with what Martijn proposed if nobody else supports my idea.
I'm okay with *not* doing the split up and going with your idea, but I think eventually such a split up would simplify things. One advantage would be that someone could examine repoze.zcml and not see distracting ZCML implementations in zope.component *too*. Regards, Martijn
Hello, * 2009-10-09 15:37, Martijn Faassen wrote:
I'm okay with *not* doing the split up and going with your idea, but I think eventually such a split up would simplify things. One advantage would be that someone could examine repoze.zcml and not see distracting ZCML implementations in zope.component *too*.
I may be wrong, but I suppose the dependency on zope.security in zope.component is the only reason why repoze.zcml is around. I tried to implement my idea here: svn://svn.zope.org/repos/main/zope.component/branches/conditional-zope.security This is a quite intrusive change, so please take it as a "suggestion" and not as a real proposal: is this the right approach? I did not (yet) write all the tests needed (and I don't like the idea of duplicating the tests in zcml_conditional.txt, to be honest). Thanks, Fabio
On 10/12/09 01:22 , Fabio Tranchitella wrote:
Hello,
* 2009-10-09 15:37, Martijn Faassen wrote:
I'm okay with *not* doing the split up and going with your idea, but I think eventually such a split up would simplify things. One advantage would be that someone could examine repoze.zcml and not see distracting ZCML implementations in zope.component *too*.
I may be wrong, but I suppose the dependency on zope.security in zope.component is the only reason why repoze.zcml is around.
Perhaps it is an idea to make zope.component an extension for repoze.zcml? repoze.zcml already exists and works well, and people who want the extra zope magic can keep using zope.component. I suspect that is less work than trying to split up zope.component. Wichert.
* 2009-10-12 08:55, Wichert Akkerman wrote:
Perhaps it is an idea to make zope.component an extension for repoze.zcml? repoze.zcml already exists and works well, and people who want the extra zope magic can keep using zope.component. I suspect that is less work than trying to split up zope.component.
repoze.zcml uses a different ZCML namespace (bfg), so you cannot replace zope.component.zcml with repoze.zcml without changing your code. Fabio
Fabio Tranchitella wrote:
* 2009-10-12 08:55, Wichert Akkerman wrote:
Perhaps it is an idea to make zope.component an extension for repoze.zcml? repoze.zcml already exists and works well, and people who want the extra zope magic can keep using zope.component. I suspect that is less work than trying to split up zope.component.
repoze.zcml uses a different ZCML namespace (bfg), so you cannot replace zope.component.zcml with repoze.zcml without changing your code.
repoze.zcml is stupid simple; its only actual value is 100% test coverage, so cutting and pasting its code will always make sense as necessary. But FTR, "using a different ZCML namespace" would be fixed by having a different meta-ZCML file for meta configuration in any other package. That meta-ZCML file would just copy the meta.zcml from repoze.zcml and change: <meta:directives namespace="http://namespaces.repoze.org/bfg"> to: <meta:directives namespace="http://namespaces.zope.org/zope"> ... leaving everything else exactly as-is. OTOH, I don't know how to both give 100% BW compat and have the "zope" namespace be the default for the adapter/utility/subscriber directives. - C
Hey, Fabio Tranchitella wrote: [snip]
I tried to implement my idea here:
svn://svn.zope.org/repos/main/zope.component/branches/conditional-zope.security
This is a quite intrusive change, so please take it as a "suggestion" and not as a real proposal: is this the right approach?
That's more or less what I have in mind. The suggestions are just about trying to make it prettier. This: if not SECURITY_SUPPORT: raise ConfigurationError("security proxied components are not " "supported because zope.security is not available") could simply become a function you can call: check_security_support() That'd be far less repetitive code. I'd also place everything you put in the 'else' branch for the import error check into a separate module. This way you don't have to define a lot of stuff on the top level. When you see something from this module in use, you *know* check_security_support() should have been executed successfully. Further improvements might be possible by an approach where instead of doing a lot of conditional checks everywhere, you define the things that do need security in such a way that they just proceed gracefully without security as well (or raise the appropriate errors). For instance, proxify() might simply not do anything, the same with protectedFactory.
I did not (yet) write all the tests needed (and I don't like the idea of duplicating the tests in zcml_conditional.txt, to be honest).
I think we need to try to separate security-related tests from the rest of the tests, and test that they fail with the right errors if zope.security is not present and do the right thing when it is. It would also be nice to be able to run the other tests with or without zope.security - the result should be identical. Regards, Martijn
* 2009-10-14 17:33, Martijn Faassen wrote:
That's more or less what I have in mind. The suggestions are just about trying to make it prettier. ... [snip]
I applied your suggestions, and I think now the code is more robust; with this branch, all the ZTK tests pass except zope.sendmail, which can be easily fixed (it is importing PermissionPublic from zope.component.zcml, which is a bad idea by itself).
I think we need to try to separate security-related tests from the rest of the tests, and test that they fail with the right errors if zope.security is not present and do the right thing when it is.
It would also be nice to be able to run the other tests with or without zope.security - the result should be identical.
Did you check the ConditionalImports test layer in my zope.component branch? It is already running the tests with and without zope.security. I want to bring the test coverage for zope.component.zcml and zope.component.security to 100% before asking to merge it back to the trunk. Any other suggestion? Thanks, Fabio
After having been sick for a week I'm back on track now... Fabio Tranchitella wrote:
I want to bring the test coverage for zope.component.zcml and zope.component.security to 100% before asking to merge it back to the trunk.
I'd like to tackle the move of zope.site.hooks to zope.component this week. While I'm sure that that wouldn't conflict with your work, I would prefer releasing both refactorings at once as they both involve using the new scheme of conditional zope.security imports. Do you suppose you could get your branch finished and merged this week? If not, I'd be willing to help you with it. -- Thomas
Hey Thomas, * 2009-10-19 10:12, Thomas Lotze wrote:
I'd like to tackle the move of zope.site.hooks to zope.component this week. While I'm sure that that wouldn't conflict with your work, I would prefer releasing both refactorings at once as they both involve using the new scheme of conditional zope.security imports. Do you suppose you could get your branch finished and merged this week? If not, I'd be willing to help you with it.
Yes, I think I can make it; I will work on this from tomorrow. We can coordinate on IRC (my nick is kobold). Thanks, Fabio
participants (7)
-
Chris McDonough -
Fabio Tranchitella -
Martijn Faassen -
Martin Aspeli -
Thomas Lotze -
Tim Hoffman -
Wichert Akkerman