Hi there, In the dependency cleanup effort we've got going on at the Grok cavesprint here at my house, we have moved code around some more. zope.security was already defining ZCML directives so we've moved the <class> directive from zope.app.component and and the <module> directive from zope.app.security into zope.security as well. These only need things that are in zope.security already (or its dependencies) and the directives are about security declarations, so they seem to fit quite well into their new place. This way we can (eventually) lift some dependencies of packages on zope.app.security and zope.app.component and point it to zope.security instead, which will help clean up the dependency structures. We've left backwards compatibility imports in place in the zope.app.* packages (hopefully enough of it) so that existing code will continue to work. Regards, Martijn
On Wed, Jan 28, 2009 at 06:42:58PM +0100, Martijn Faassen wrote:
Hi there,
In the dependency cleanup effort we've got going on at the Grok cavesprint here at my house, we have moved code around some more.
zope.security was already defining ZCML directives so we've moved the <class> directive from zope.app.component and and the <module> directive from zope.app.security into zope.security as well. These only need things that are in zope.security already (or its dependencies) and the directives are about security declarations, so they seem to fit quite well into their new place.
Sounds good! What about the other use case of <class>, i.e. declaring implemented interfaces, as in <class class=".foreignmodule.SomeClass"> <implements interface=".interfaces.ISomeInterface" /> </class> ? Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
2009/1/29 Marius Gedminas <marius@gedmin.as>:
On Wed, Jan 28, 2009 at 06:42:58PM +0100, Martijn Faassen wrote:
Hi there,
In the dependency cleanup effort we've got going on at the Grok cavesprint here at my house, we have moved code around some more.
zope.security was already defining ZCML directives so we've moved the <class> directive from zope.app.component and and the <module> directive from zope.app.security into zope.security as well. These only need things that are in zope.security already (or its dependencies) and the directives are about security declarations, so they seem to fit quite well into their new place.
Sounds good!
What about the other use case of <class>, i.e. declaring implemented interfaces, as in
<class class=".foreignmodule.SomeClass"> <implements interface=".interfaces.ISomeInterface" /> </class>
+1. That's kinda strange to have it in zope.security. I think, the better place to move zcml directives is zope.component, as it already depends on zope.security for the zcml support and the "class" directive also has component-related "factory" subdirective which declared in zope.component. -- WBR, Dan Korostelev
On Wednesday 28 January 2009, Dan Korostelev wrote:
I think, the better place to move zcml directives is zope.component, as it already depends on zope.security for the zcml support and the "class" directive also has component-related "factory" subdirective which declared in zope.component.
Good point. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hey, Dan Korostelev wrote: [snip]
What about the other use case of <class>, i.e. declaring implemented interfaces, as in
<class class=".foreignmodule.SomeClass"> <implements interface=".interfaces.ISomeInterface" /> </class>
+1. That's kinda strange to have it in zope.security.
I think, the better place to move zcml directives is zope.component, as it already depends on zope.security for the zcml support and the "class" directive also has component-related "factory" subdirective which declared in zope.component.
It's true <class> isn't purely about security. It's not purely about component configuration either, though. Most of what 'class' is about is security-related, so it's using a lot of stuff in zope.security. If you look at the implementation, I think people would agree it's doing more security manipulation then it's doing component configuration. And I think we can at least agree zope.security is at least an improvement in location compared to their scattered implementation throughout zope.app.component and zope.app.security. So, I don't think we'll be moving <class> (and then <module>) into zope.component this week during the sprint, and not just because it'd distract us from our main goal to reach layered dependencies. I believe that zope.component relying on zope.security (if indeed [zcml] is enabled) is actually something that could be avoided if we moved the ZCML directive implementations from zope.component entirely. When you install zope.component without ZCML support, you get a reasonable dependency list actually installed. When you do use the ZCML dependency it starts pulling in a lot more, including quite unreasonable stuff like zope.publisher and zope.traversing. See this for more information: http://plope.com/Members/chrism/pluginizing_an_app I believe it'd be nicer to extract any ZCML related stuff from zope.component at some point and put it into zope.componentzcml or something like that. We could then decide to move the <class> and <module> directives in there as well. Regards, Martijn
On Thu, Jan 29, 2009 at 4:01 AM, Martijn Faassen <faassen@startifact.com> wrote:
I believe it'd be nicer to extract any ZCML related stuff from zope.component at some point and put it into zope.componentzcml or something like that. We could then decide to move the <class> and <module> directives in there as well.
+1 This makes a lot more sense to me than having the ZCML support in either zope.component or zope.security. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Fred Drake wrote:
On Thu, Jan 29, 2009 at 4:01 AM, Martijn Faassen <faassen@startifact.com> wrote:
I believe it'd be nicer to extract any ZCML related stuff from zope.component at some point and put it into zope.componentzcml or something like that. We could then decide to move the <class> and <module> directives in there as well.
+1
This makes a lot more sense to me than having the ZCML support in either zope.component or zope.security.
Indeed, surely all zcml stuff belongs in zope.configuration anyway? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Fred Drake wrote:
On Thu, Jan 29, 2009 at 4:01 AM, Martijn Faassen <faassen@startifact.com> wrote:
I believe it'd be nicer to extract any ZCML related stuff from zope.component at some point and put it into zope.componentzcml or something like that. We could then decide to move the <class> and <module> directives in there as well. +1
This makes a lot more sense to me than having the ZCML support in either zope.component or zope.security.
Indeed, surely all zcml stuff belongs in zope.configuration anyway?
No, not there either, as zope.configuration doesn't define *any* directives except the basic ones like 'include' and 'configure'. If you would implement zope 3's directives in zope.configuration it'd start pulling in dependencies like crazies, creating more dependency cycles. I think a new package might be in order. Regards, Martijn
Martijn Faassen wrote:
This makes a lot more sense to me than having the ZCML support in either zope.component or zope.security. Indeed, surely all zcml stuff belongs in zope.configuration anyway?
No, not there either, as zope.configuration doesn't define *any* directives except the basic ones like 'include' and 'configure'. If you would implement zope 3's directives in zope.configuration it'd start pulling in dependencies like crazies, creating more dependency cycles.
I think a new package might be in order.
Indeed, maybe: zope.configuration.x zope.configuration.y etc... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Fri, Jan 30, 2009 at 05:32:33PM +0000, Chris Withers wrote:
Martijn Faassen wrote:
This makes a lot more sense to me than having the ZCML support in either zope.component or zope.security. Indeed, surely all zcml stuff belongs in zope.configuration anyway?
No, not there either, as zope.configuration doesn't define *any* directives except the basic ones like 'include' and 'configure'. If you would implement zope 3's directives in zope.configuration it'd start pulling in dependencies like crazies, creating more dependency cycles.
I think a new package might be in order.
Indeed, maybe:
zope.configuration.x zope.configuration.y
Please don't, having namespace packages that contain files (as zope.configuration already does) breaks setuptools.
etc...
cheers,
Chris
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- Brian Sutherland
Brian Sutherland wrote:
zope.configuration.x zope.configuration.y
Please don't, having namespace packages that contain files (as zope.configuration already does) breaks setuptools.
Then setuptools needs fixing. There's no reason why zope.configuration and zope.configuration.x shouldn't happilly co-exist... (Marc-André Lemburg of the mx* library set assures me it is possible...) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2009-1-30 18:50 +0000:
Brian Sutherland wrote:
zope.configuration.x zope.configuration.y
Please don't, having namespace packages that contain files (as zope.configuration already does) breaks setuptools.
Then setuptools needs fixing.
But not for this purpose: I would find is very unintuitive when configuration were centralized (in subpackages of "zope.configuration") rather than modular. Configuration belongs to the application or framework component that depends on this configuration not to any central component. -- Dieter
Dieter Maurer wrote:
Chris Withers wrote at 2009-1-30 18:50 +0000:
Brian Sutherland wrote:
zope.configuration.x zope.configuration.y Please don't, having namespace packages that contain files (as zope.configuration already does) breaks setuptools. Then setuptools needs fixing.
But not for this purpose:
I would find is very unintuitive when configuration were centralized (in subpackages of "zope.configuration") rather than modular.
Configuration belongs to the application or framework component that depends on this configuration not to any central component.
I would normally agree, but this isn't quite as simple as that. ZCML cuts across packages in that, if you use ZCML, you want the directives for all the packages you have installed. If you don't use ZCML, you don't want any of the directives. using --> to mean depends on, what we want is: zope.configuration ^ | zcmlforpackagez --> packagex ...which frees up packagex to be used without any ZCML So, we end up with lots of "zcmlforpackage"'s which need to go somewhere. Either zope.configuration.packagex or packagex.zcml as package names for these seems sensible, but if setuptools doesn't support either, then it needs fixing... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
2009/2/6 Chris Withers <chris@simplistix.co.uk>:
Dieter Maurer wrote:
Chris Withers wrote at 2009-1-30 18:50 +0000:
Brian Sutherland wrote:
zope.configuration.x zope.configuration.y Please don't, having namespace packages that contain files (as zope.configuration already does) breaks setuptools. Then setuptools needs fixing.
But not for this purpose:
I would find is very unintuitive when configuration were centralized (in subpackages of "zope.configuration") rather than modular.
Configuration belongs to the application or framework component that depends on this configuration not to any central component.
I would normally agree, but this isn't quite as simple as that. ZCML cuts across packages in that, if you use ZCML, you want the directives for all the packages you have installed.
If you don't use ZCML, you don't want any of the directives.
using --> to mean depends on, what we want is:
zope.configuration ^ | zcmlforpackagez --> packagex
...which frees up packagex to be used without any ZCML
So, we end up with lots of "zcmlforpackage"'s which need to go somewhere.
Either zope.configuration.packagex or packagex.zcml as package names for these seems sensible, but if setuptools doesn't support either, then it needs fixing...
Why not just define an extra requirement for zcml in the main package and not generate thousands of packages that contain only meta directives? -- WBR, Dan Korostelev
Chris Withers wrote at 2009-2-6 12:31 +0000:
...
I would find is very unintuitive when configuration were centralized (in subpackages of "zope.configuration") rather than modular.
Configuration belongs to the application or framework component that depends on this configuration not to any central component.
I would normally agree, but this isn't quite as simple as that. ZCML cuts across packages in that, if you use ZCML, you want the directives for all the packages you have installed.
At least, I want only the directives for the packages I have *really* installed. Think of the dependancy monster a common configuration package would be. And even when I have a package installed, I may not want its registrations (because they are inadequate for me and I want to provide my own).
If you don't use ZCML, you don't want any of the directives.
using --> to mean depends on, what we want is:
zope.configuration ^ | zcmlforpackagez --> packagex
...which frees up packagex to be used without any ZCML
Apparently, you treat "zope.configuration" as a namespace package and you will never install "zope.configuration" as a whole but only the lower packages -- that might work. Nevertheless, I find it highly unintuitive to rip of the configuration and put it at a completely different place. Package names of the form "packagex" and "packagex_zcml" seem far more intuitive for me. Note that below "zope.configuration" you have to retain the namepaces of your packages to avoid name conflicts and provide a homogenous map between package and its configuration package. You would get subpackages "zope.configuration.zope.proxy", "zope.configuration.z3c.XXXX".... Nasty.... -- Dieter
On Jan 30, 2009, at 1:48 PM, Brian Sutherland wrote:
Please don't, having namespace packages that contain files (as zope.configuration already does) breaks setuptools.
zope.configuration isn't a namespace package. It is simply a package with subpackages. Jim -- Jim Fulton Zope Corporation
On Sat, Jan 31, 2009 at 06:21:27AM -0500, Jim Fulton wrote:
On Jan 30, 2009, at 1:48 PM, Brian Sutherland wrote:
Please don't, having namespace packages that contain files (as zope.configuration already does) breaks setuptools.
zope.configuration isn't a namespace package. It is simply a package with subpackages.
I assumed Chris' suggestion was to make zope.configuration a namespace package.
Jim
-- Jim Fulton Zope Corporation
-- Brian Sutherland
Jim Fulton wrote:
zope.configuration isn't a namespace package. It is simply a package with subpackages.
Does setuptools support something like: "packagea": packagea/__init__.py packagea/amodule.py "packagea.something": packagea/__init__.py packagea/something/__init__.py packagea/something/bmodule.py If so, which packagea/__init__.py gets used? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Fri, 06 Feb 2009 12:35:09 +0000 Chris Withers <chris@simplistix.co.uk> wrote:
Jim Fulton wrote:
zope.configuration isn't a namespace package. It is simply a package with subpackages.
Does setuptools support something like:
"packagea": packagea/__init__.py packagea/amodule.py
"packagea.something": packagea/__init__.py packagea/something/__init__.py packagea/something/bmodule.py
If so, which packagea/__init__.py gets used?
It does. You're supposed to assume that neither __init__.py gets used. -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Feb 6, 2009, at 7:35 AM, Chris Withers wrote:
Jim Fulton wrote:
zope.configuration isn't a namespace package. It is simply a package with subpackages.
Does setuptools support something like:
"packagea": packagea/__init__.py packagea/amodule.py
"packagea.something": packagea/__init__.py packagea/something/__init__.py packagea/something/bmodule.py
No.
If so, which packagea/__init__.py gets used?
That's why it doesn't. :) That's also why zope.configuration isn't a namespace package. Jim -- Jim Fulton Zope Corporation
On Fri, 6 Feb 2009 12:24:14 -0500 Jim Fulton <jim@zope.com> wrote:
On Feb 6, 2009, at 7:35 AM, Chris Withers wrote:
Jim Fulton wrote:
zope.configuration isn't a namespace package. It is simply a package with subpackages.
Does setuptools support something like:
"packagea": packagea/__init__.py packagea/amodule.py
"packagea.something": packagea/__init__.py packagea/something/__init__.py packagea/something/bmodule.py
No.
According to the setuptools documentation and our experiments on the sprint, this is supposed to work and does work: "When you declare a package to be a namespace package, it means that the package has no meaningful contents in its __init__.py, and that it is merely a container for modules and subpackages."
If so, which packagea/__init__.py gets used?
Only the __init__.py isn't allowed to have code is what I read from the documentation.
That's why it doesn't. :) That's also why zope.configuration isn't a namespace package.
I'm not arguing to turn it into a namespace package, I just wanted to point out the technical issues are different. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Christian Theune wrote at 2009-2-7 09:36 +0100:
... According to the setuptools documentation and our experiments on the sprint, this is supposed to work and does work:
"When you declare a package to be a namespace package, it means that the package has no meaningful contents in its __init__.py, and that it is merely a container for modules and subpackages."
If so, which packagea/__init__.py gets used?
Only the __init__.py isn't allowed to have code is what I read from the documentation.
However, extreme care must be taken to avoid name clashes. For Modules/packages with the same name it is not deterministic which of them will actually be loaded. "__init__.py" is just a common case of this problem. -- Dieter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dieter Maurer wrote:
Christian Theune wrote at 2009-2-7 09:36 +0100:
... According to the setuptools documentation and our experiments on the sprint, this is supposed to work and does work:
"When you declare a package to be a namespace package, it means that the package has no meaningful contents in its __init__.py, and that it is merely a container for modules and subpackages."
If so, which packagea/__init__.py gets used? Only the __init__.py isn't allowed to have code is what I read from the documentation.
However, extreme care must be taken to avoid name clashes.
As with any namespace, sure. But there would be no point in namespace packages at all if modules or subpackages couldn't be placed in them.
For Modules/packages with the same name it is not deterministic which of them will actually be loaded. "__init__.py" is just a common case of this problem.
It is the one which is guaranteed to clash, since its absence makes a directory not-a-package at all. Setuptools documents that every directory participating in a namespace package must have the "declare a namespace" boilerplate in its __init__.py, and *nothing else*. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJkEhY+gerLs4ltQ4RAqxIAJ9ds65eHMxyMFjltbPrSglCe03KHQCfVSyS UHJV4bm84NLy29xhNJzfz8o= =6Htc -----END PGP SIGNATURE-----
On Jan 30, 2009, at 12:01 PM, Martijn Faassen wrote:
Chris Withers wrote:
Fred Drake wrote:
On Thu, Jan 29, 2009 at 4:01 AM, Martijn Faassen <faassen@startifact.com
wrote: I believe it'd be nicer to extract any ZCML related stuff from zope.component at some point and put it into zope.componentzcml or something like that. We could then decide to move the <class> and <module> directives in there as well. +1
This makes a lot more sense to me than having the ZCML support in either zope.component or zope.security.
Indeed, surely all zcml stuff belongs in zope.configuration anyway?
No, not there either, as zope.configuration doesn't define *any* directives except the basic ones like 'include' and 'configure'. If you would implement zope 3's directives in zope.configuration it'd start pulling in dependencies like crazies, creating more dependency cycles.
I think a new package might be in order.
Yes please. (I should have read this before sending the other message I just sent. :) Jim -- Jim Fulton Zope Corporation
On Fri, Jan 30, 2009 at 12:01 PM, Martijn Faassen <faassen@startifact.com> wrote:
No, not there either, as zope.configuration doesn't define *any* directives except the basic ones like 'include' and 'configure'. If you would implement zope 3's directives in zope.configuration it'd start pulling in dependencies like crazies, creating more dependency cycles.
I think a new package might be in order.
How about a namespace package zope.zcml? -- Benji York Senior Software Engineer Zope Corporation
Benji York wrote:
On Fri, Jan 30, 2009 at 12:01 PM, Martijn Faassen <faassen@startifact.com> wrote:
No, not there either, as zope.configuration doesn't define *any* directives except the basic ones like 'include' and 'configure'. If you would implement zope 3's directives in zope.configuration it'd start pulling in dependencies like crazies, creating more dependency cycles.
I think a new package might be in order.
How about a namespace package zope.zcml?
I think something like this would be a good idea. Though grokcore.* packages would also depend on some of the configuration actions defined there and they don't use ZCML themselves, it wouldn't pull in any dependencies that they wouldn't already need anyway. Regards, Martijn
On Fri, Jan 30, 2009 at 4:44 PM, Martijn Faassen <faassen@startifact.com> wrote:
Benji York wrote:
On Fri, Jan 30, 2009 at 12:01 PM, Martijn Faassen <faassen@startifact.com> wrote:
No, not there either, as zope.configuration doesn't define *any* directives except the basic ones like 'include' and 'configure'. If you would implement zope 3's directives in zope.configuration it'd start pulling in dependencies like crazies, creating more dependency cycles.
I think a new package might be in order.
How about a namespace package zope.zcml?
I think something like this would be a good idea. Though grokcore.* packages would also depend on some of the configuration actions defined there and they don't use ZCML themselves, it wouldn't pull in any dependencies that they wouldn't already need anyway.
Crazier idea: make the namespace package "zcml". -- Benji York Senior Software Engineer Zope Corporation
On Jan 30, 2009, at 6:59 AM, Chris Withers wrote:
Fred Drake wrote:
On Thu, Jan 29, 2009 at 4:01 AM, Martijn Faassen <faassen@startifact.com
wrote: I believe it'd be nicer to extract any ZCML related stuff from zope.component at some point and put it into zope.componentzcml or something like that. We could then decide to move the <class> and <module> directives in there as well.
+1
This makes a lot more sense to me than having the ZCML support in either zope.component or zope.security.
Indeed, surely all zcml stuff belongs in zope.configuration anyway?
No!!!!!!! zope.configuration just contains the implmentation of zcml itself. It shouldn't have any application-dependent code. I have no problem with moving zcml out of other packages, but it has to move into new packages, not into zope.configuration. Jim -- Jim Fulton Zope Corporation
On Wednesday 28 January 2009, Marius Gedminas wrote:
Sounds good!
What about the other use case of <class>, i.e. declaring implemented interfaces, as in
<class class=".foreignmodule.SomeClass"> <implements interface=".interfaces.ISomeInterface" /> </class>
I was waiting for that comment. :-) I wanted to write the same this morning, but then decided that the new solution is better than anything else I could think of. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
participants (12)
-
Benji York -
Brian Sutherland -
Chris Withers -
Christian Theune -
Dan Korostelev -
Dieter Maurer -
Fred Drake -
Jim Fulton -
Marius Gedminas -
Martijn Faassen -
Stephan Richter -
Tres Seaver