Mailing List Archive: Zope: Dev

zope.site.hooks

Index | Next | Previous | View Threaded

tl at gocept

Oct 6, 2009, 7:45 AM

Post #1 of 22 (2187 views)
Permalink

zope.site.hooks

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Oct 6, 2009, 1:47 PM

Post #2 of 22 (2139 views)
Permalink

Re: zope.site.hooks [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

optilude+lists at gmail

Oct 6, 2009, 5:49 PM

Post #3 of 22 (2142 views)
Permalink

Re: zope.site.hooks [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

zutesmog at gmail

Oct 6, 2009, 6:24 PM

Post #4 of 22 (2125 views)
Permalink

Re: zope.site.hooks [In reply to]

Hi

On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli <optilude+lists [at] gmail> 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 [at] zope
> 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 )
>
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

tl at gocept

Oct 6, 2009, 11:14 PM

Post #5 of 22 (2123 views)
Permalink

Re: zope.site.hooks [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

tl at gocept

Oct 6, 2009, 11:57 PM

Post #6 of 22 (2112 views)
Permalink

Re: zope.site.hooks [In reply to]

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 [at] zope
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 )

zutesmog at gmail

Oct 7, 2009, 12:47 AM

Post #7 of 22 (2109 views)
Permalink

Re: zope.site.hooks [In reply to]

> 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 [at] gocept> 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 [at] zope
> 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 )
>
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

tl at gocept

Oct 7, 2009, 12:55 AM

Post #8 of 22 (2114 views)
Permalink

Re: zope.site.hooks [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Oct 7, 2009, 1:19 PM

Post #9 of 22 (2111 views)
Permalink

Re: zope.site.hooks [In reply to]

Tim Hoffman wrote:
> On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli <optilude+lists [at] gmail> 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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Oct 7, 2009, 1:25 PM

Post #10 of 22 (2107 views)
Permalink

Re: zope.site.hooks [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

kobold at kobold

Oct 8, 2009, 11:18 PM

Post #11 of 22 (2096 views)
Permalink

Re: zope.site.hooks [In reply to]

* 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Oct 9, 2009, 4:58 AM

Post #12 of 22 (2099 views)
Permalink

Re: zope.site.hooks [In reply to]

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 [at] zope
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 )

kobold at kobold

Oct 9, 2009, 5:32 AM

Post #13 of 22 (2090 views)
Permalink

Re: zope.site.hooks [In reply to]

* 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Oct 9, 2009, 6:36 AM

Post #14 of 22 (2086 views)
Permalink

Re: zope.site.hooks [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

kobold at kobold

Oct 11, 2009, 4:22 PM

Post #15 of 22 (2034 views)
Permalink

Re: zope.site.hooks [In reply to]

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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

wichert at wiggy

Oct 11, 2009, 11:54 PM

Post #16 of 22 (2030 views)
Permalink

Re: zope.site.hooks [In reply to]

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.

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

kobold at kobold

Oct 11, 2009, 11:58 PM

Post #17 of 22 (2025 views)
Permalink

Re: zope.site.hooks [In reply to]

* 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

chrism at plope

Oct 12, 2009, 8:59 PM

Post #18 of 22 (2005 views)
Permalink

Re: zope.site.hooks [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Oct 14, 2009, 8:32 AM

Post #19 of 22 (1937 views)
Permalink

Re: zope.site.hooks [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

kobold at kobold

Oct 16, 2009, 11:07 AM

Post #20 of 22 (1848 views)
Permalink

Re: zope.site.hooks [In reply to]

* 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

tl at gocept

Oct 19, 2009, 1:11 AM

Post #21 of 22 (1769 views)
Permalink

Re: zope.site.hooks [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

kobold at kobold

Oct 19, 2009, 1:30 AM

Post #22 of 22 (1753 views)
Permalink

Re: zope.site.hooks [In reply to]

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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads