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