I just noticed that zope.traversing depends on dozens of packages, most of them (including a lot of zope.app stuff and the ZODB) only through the dependency on zope.app.applicationcontrol. According to the zope.traversing code, the only occasion on which zope.traversing needs zope.app.applicationcontrol is if some special name is to be traversed in the etc namespace. I suggest trying to import zope.app.applicationcontrol in that case instead of doing it unconditionally, and passing if an ImportError is raised. AFAICS this would result in the names simply not being available if the application controller isn't, which seems sensible to me. I think it is in favour of this suggestion that a comment above the application controller lookup states that the hard-coding was meant only as a preliminary measure until "some sort of registry" takes its place. Unless I overlooked something, this rather simple change would do no harm while shedding a large number of dependencies. Opinions? -- Thomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Lotze wrote:
I just noticed that zope.traversing depends on dozens of packages, most of them (including a lot of zope.app stuff and the ZODB) only through the dependency on zope.app.applicationcontrol. According to the zope.traversing code, the only occasion on which zope.traversing needs zope.app.applicationcontrol is if some special name is to be traversed in the etc namespace.
I suggest trying to import zope.app.applicationcontrol in that case instead of doing it unconditionally, and passing if an ImportError is raised. AFAICS this would result in the names simply not being available if the application controller isn't, which seems sensible to me.
I think it is in favour of this suggestion that a comment above the application controller lookup states that the hard-coding was meant only as a preliminary measure until "some sort of registry" takes its place.
Unless I overlooked something, this rather simple change would do no harm while shedding a large number of dependencies.
Opinions?
+100 to shedding the dependencies. Could we have the conditional import work as a fallback to a utility lookup? And then change 'zope.applicationcontrol' to register such a utility? 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 iD8DBQFHQ0Uh+gerLs4ltQ4RAqPZAJ9dRnthdxB3B8rKxhlF59IZOyJ+/gCgyfNn wTlnEgYTPqfkZL9o7rfK5wU= =FILi -----END PGP SIGNATURE-----
Tres Seaver wrote:
+100 to shedding the dependencies. Could we have the conditional import work as a fallback to a utility lookup? And then change 'zope.applicationcontrol' to register such a utility?
This should be possible, but the utility lookup would have to be conditional as well since it would have to target zope.app.applicationcontrol.interfaces.IApplicationControl which may not be available either after the dependency on zope.app.applicationcontrol has been lifted. OTOH, if the application controller were to be registered as a utility, should it stay importable from the module, at least for a transition period? If zope.app.applicationcontrol.applicationController was removed, would it be sufficient to adapt the zope.app.publication tests, or are there other packages expected to break in that case? Philosophically, when is it best to provide something like the application controller as a global utility and when is it sufficient to bind it to a name in a module? -- Thomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Lotze wrote:
Tres Seaver wrote:
+100 to shedding the dependencies. Could we have the conditional import work as a fallback to a utility lookup? And then change 'zope.applicationcontrol' to register such a utility?
This should be possible, but the utility lookup would have to be conditional as well since it would have to target zope.app.applicationcontrol.interfaces.IApplicationControl which may not be available either after the dependency on zope.app.applicationcontrol has been lifted.
Hmm, I guess I hadn't realized that the interface was in the zope.app package. Shouldn't the interface be in a more "dependable" package, from which clients can import it without depending on a given implementation? One logical place for the interface is actually in zope.traversing: that would break the dependency inversion.
OTOH, if the application controller were to be registered as a utility, should it stay importable from the module, at least for a transition period? If zope.app.applicationcontrol.applicationController was removed, would it be sufficient to adapt the zope.app.publication tests, or are there other packages expected to break in that case?
Philosophically, when is it best to provide something like the application controller as a global utility and when is it sufficient to bind it to a name in a module?
Philosophically, a utility lookup allows for pluggability: it is a looser coupling (to the implementation) than an import. I would prefer such an indirection over dependency cycles, any day of the week. 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 iD8DBQFHRIAs+gerLs4ltQ4RAuf3AJ0eQtloAkzay4NlbEbYob5sUJh4+QCgr1M4 bAqX0YqQrxpq1A5/Ir1cPiw= =NQgZ -----END PGP SIGNATURE-----
Tres Seaver wrote:
zope.app.applicationcontrol.interfaces.IApplicationControl which may not be available either after the dependency on zope.app.applicationcontrol has been lifted.
Hmm, I guess I hadn't realized that the interface was in the zope.app package. Shouldn't the interface be in a more "dependable" package, from which clients can import it without depending on a given implementation? One logical place for the interface is actually in zope.traversing: that would break the dependency inversion.
OTOH I don't think that the concept of the application controller should be mentioned in zope.traversing which is about something else entirely. I do think that this sounds like the perfect reason to introduce that registry: Some interface IEtcTraverser or similiar might be introduced against which named subscription adapters might be registered. Then, zope.app.application could register its own code to handle the "process" and "applicationControl" names. -- Thomas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Lotze wrote:
Tres Seaver wrote:
zope.app.applicationcontrol.interfaces.IApplicationControl which may not be available either after the dependency on zope.app.applicationcontrol has been lifted. Hmm, I guess I hadn't realized that the interface was in the zope.app package. Shouldn't the interface be in a more "dependable" package, from which clients can import it without depending on a given implementation? One logical place for the interface is actually in zope.traversing: that would break the dependency inversion.
OTOH I don't think that the concept of the application controller should be mentioned in zope.traversing which is about something else entirely. I do think that this sounds like the perfect reason to introduce that registry: Some interface IEtcTraverser or similiar might be introduced against which named subscription adapters might be registered. Then, zope.app.application could register its own code to handle the "process" and "applicationControl" names.
I think that sounds like the right plan: zope.traversing then has no inappropriate dependencies, and the application controller package can just register named global utilities (or named adapters, if that fits better), for the generic interface. 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 iD8DBQFHRZ/5+gerLs4ltQ4RAoSkAJ9FcPbSguQHJSaEscCW8Pfr/gkKRwCfXEnr mTO8OWULwNfeMl8pbizJy9Y= =QJyG -----END PGP SIGNATURE-----
On Tuesday 20 November 2007, Thomas Lotze wrote:
Opinions?
I think the application control namespace code could simply be moved to zope.app.applicationcontrol, since the latter package does needs zope.traversing anyways. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
I think the application control namespace code could simply be moved to zope.app.applicationcontrol, since the latter package does needs zope.traversing anyways.
True, but I don't see how to do this cleanly as long as the namespace handler for the etc namespace is implemented as straight-forward as it is now. Have we reached the point where we want to introduce that registry the comment in zope.traversing.namespace.etc.traverse suggests? -- Thomas
participants (3)
-
Stephan Richter -
Thomas Lotze -
Tres Seaver