zope.app.publication dependencies (volunteers needed!)
Hi there, zope.app.publisher is depended on by quite a bit of code that uses the Zope Toolkit, as it defines brower:view and browser:resource and the like. Unfortunately zope.app.publisher currently depends on more than 60 packages. This is rather excessive, and we'd like to cut down on this. Also interesting about zope.app.publisher is that while it defines a 'browser' directory it actually doesn't contain any ZMI code; instead ZCML directives are defined there. Refactoring so the ZMI isn't around anymore is usually a good first step, but that's not needed here. If you look at the dependency graph for zope.app.publisher the task of fixing this looks daunting: http://startifact.com/depgraphs/zope.app.publisher.svg But now please observe the following: http://startifact.com/depgraphs/zope_app_publisher_cycles.svg This identifies the main cycles in that dependency graph. If we break those in the right way, we can cut down a lot of dependencies in one go. Getting rid of the zope.app.form and zope.formlib dependencies looks like a sensible step. From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are): * cut the dependency of zope.app.publisher on zope.app.component * OR cut the dependency of zope.app.component on zope.formlib * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.component on zope.app.security * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.publication on zope.app.exception * OR cut the dependency of zope.app.exception on zope.formlib There are probably a few more options there, but given that small graph, you get the picture. Any volunteers to do this research on how hard some of these steps would look and report back here? Once we've discussed the options we can proceed fixing the problem. Regards, Martijn
Am 13.05.2009 um 19:55 schrieb Martijn Faassen: [...]
From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are):
* cut the dependency of zope.app.publisher on zope.app.component
* OR cut the dependency of zope.app.component on zope.formlib
* cut the dependency of zope.app.publisher on zope.app.publication
* OR cut the dependency of zope.app.component on zope.app.security
* cut the dependency of zope.app.publisher on zope.app.publication
* OR cut the dependency of zope.app.publication on zope.app.exception
* OR cut the dependency of zope.app.exception on zope.formlib
The last option I already implemented on the icemac_no_formlib branch in zope.app.exception. z3c.template is used there instead of zope.formlib. I can merge this branch in the next days and cut a release. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Michael
Betreff: Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
Am 13.05.2009 um 19:55 schrieb Martijn Faassen: [...]
From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are):
* cut the dependency of zope.app.publisher on zope.app.component
* OR cut the dependency of zope.app.component on zope.formlib
* cut the dependency of zope.app.publisher on zope.app.publication
* OR cut the dependency of zope.app.component on zope.app.security
* cut the dependency of zope.app.publisher on zope.app.publication
* OR cut the dependency of zope.app.publication on zope.app.exception
* OR cut the dependency of zope.app.exception on zope.formlib
The last option I already implemented on the icemac_no_formlib branch in zope.app.exception. z3c.template is used there instead of zope.formlib.
I can merge this branch in the next days and cut a release.
As long as z3c.template depends on chameleon, lxml etc. I think this is a no go for core zope packages. We need to get rid of z3c.pt and offer a better optional implementation for z3c.pt support. note; I like z3c.pt very much and think this is a great package. But the built in compatibility layer is a very bad thing. Regards Roger Ineichen _____________________________ END OF MESSAGE
Am 14.05.2009 um 11:00 schrieb Roger Ineichen:
The last option I already implemented on the icemac_no_formlib branch in zope.app.exception. z3c.template is used there instead of zope.formlib.
I can merge this branch in the next days and cut a release.
As long as z3c.template depends on chameleon, lxml etc. I think this is a no go for core zope packages.
According to its setup.py z3c.template does not depend on chameleon. It depends on "z3c.ptcompat [zpt]" which does not depend on z3c.pt but only on zope.app.pagetemplate.
We need to get rid of z3c.pt and offer a better optional implementation for z3c.pt support.
This is right but another problem.
note; I like z3c.pt very much and think this is a great package. But the built in compatibility layer is a very bad thing.
Mit freundlichen Grüßen -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Michael Howitz wrote:
Am 14.05.2009 um 11:00 schrieb Roger Ineichen:
The last option I already implemented on the icemac_no_formlib branch in zope.app.exception. z3c.template is used there instead of zope.formlib.
I can merge this branch in the next days and cut a release. As long as z3c.template depends on chameleon, lxml etc. I think this is a no go for core zope packages.
According to its setup.py z3c.template does not depend on chameleon. It depends on "z3c.ptcompat [zpt]" which does not depend on z3c.pt but only on zope.app.pagetemplate.
I still think there's a problem in pulling in 2 more packages. zope.app.exception is not a big package in the amount of code inside.. Could you talk a bit about what your branch is trying to accomplish? (see elsewhere on the thread for a way to cut the dependency of zope.app.publication to zope.app.exception completely with little effort) Regards, Martijn
Am 14.05.2009 um 12:05 schrieb Martijn Faassen:
Michael Howitz wrote:
Am 14.05.2009 um 11:00 schrieb Roger Ineichen:
The last option I already implemented on the icemac_no_formlib branch in zope.app.exception. z3c.template is used there instead of zope.formlib.
I can merge this branch in the next days and cut a release. As long as z3c.template depends on chameleon, lxml etc. I think this is a no go for core zope packages.
According to its setup.py z3c.template does not depend on chameleon. It depends on "z3c.ptcompat [zpt]" which does not depend on z3c.pt but only on zope.app.pagetemplate.
I still think there's a problem in pulling in 2 more packages. zope.app.exception is not a big package in the amount of code inside..
Could you talk a bit about what your branch is trying to accomplish?
zope.app.exception depends on zope.formlib's namedtemplate mechanism. zope.formlib has many many dependencies but only this special function of it is used by zope.app.exception. It's needed to render customizable the unauthorized views. So I replaced zope.formlib by the much more lightweight z3c.template. See also the proposal http://mail.zope.org/pipermail/zope-dev/2009-April/035833.html
(see elsewhere on the thread for a way to cut the dependency of zope.app.publication to zope.app.exception completely with little effort)
This (move the ISystemErrorView) seems to be the right solution to get rid of the zope.app.publication dependency on zope.app.exception. In a project of mine I need zope.app.exception independently of this dependency but I do not want to depend on zope.formlib for a little feature of it which can be done by another smaller package. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Michael Howitz wrote:
Am 14.05.2009 um 12:05 schrieb Martijn Faassen: [snip]
Could you talk a bit about what your branch is trying to accomplish?
zope.app.exception depends on zope.formlib's namedtemplate mechanism. zope.formlib has many many dependencies but only this special function of it is used by zope.app.exception. It's needed to render customizable the unauthorized views. So I replaced zope.formlib by the much more lightweight z3c.template.
Is this replacement compatible with zope.formlib's namedtemplate mechanism? Will anything break? The guaranteed compatible step forward to reduce dependencies would be to extract the namedtemplate mechanism from zope.formlib and place that somewhere else. zope.formlib can then have an import for backwards compatibility.
See also the proposal http://mail.zope.org/pipermail/zope-dev/2009-April/035833.html
I missed this discussion then, my apologies. I still stand by my opinion that this would suddenly pull in *new* libraries in with a significant chunk of new code, and we need to be very careful with that and not just do it to lift a dependency.
(see elsewhere on the thread for a way to cut the dependency of zope.app.publication to zope.app.exception completely with little effort)
This (move the ISystemErrorView) seems to be the right solution to get rid of the zope.app.publication dependency on zope.app.exception. In a project of mine I need zope.app.exception independently of this dependency but I do not want to depend on zope.formlib for a little feature of it which can be done by another smaller package.
I understand. Why not move the namedtemplate mechanism somewhere else entirely, though? This way we'd not introduce new code. The namedtemplate code itself only seems to depend on zope.traversing, but that doesn't sound like a good home. The tests depend on zope.app.pagetemplate, so perhaps it should move there? This is still a dependency of zope.app.exception anyway, and it itself doesn't appear to depend on zope.formlib. zope.app.exception's UI bits are a curious case in that they're not really part of the ZMI, though they integrate with the ZMI and assume the existence of some macros. It's also a zope.app.* package and we'd like to get rid of those in the toolkit. What to do with it? Regards, Martijn
Am 14.05.2009 um 15:02 schrieb Martijn Faassen:
Michael Howitz wrote:
Am 14.05.2009 um 12:05 schrieb Martijn Faassen: [snip]
Could you talk a bit about what your branch is trying to accomplish?
zope.app.exception depends on zope.formlib's namedtemplate mechanism. zope.formlib has many many dependencies but only this special function of it is used by zope.app.exception. It's needed to render customizable the unauthorized views. So I replaced zope.formlib by the much more lightweight z3c.template.
Is this replacement compatible with zope.formlib's namedtemplate mechanism? Will anything break?
No it is not compatible. So I think it's a bad idea. Breaking the dependency between zope.app.publication and zope.app.exception by moving the ISystemErrorView interface and maybe the class which implements it to zope.browser would be better. I'll look into it at weekend.
The guaranteed compatible step forward to reduce dependencies would be to extract the namedtemplate mechanism from zope.formlib and place that somewhere else. zope.formlib can then have an import for backwards compatibility.
Maybe, but is this namedtemplate mechanism used outside zope.formlib? If so we should extract it.
See also the proposal http://mail.zope.org/pipermail/zope-dev/2009-April/035833.html
I missed this discussion then, my apologies. I still stand by my opinion that this would suddenly pull in *new* libraries in with a significant chunk of new code, and we need to be very careful with that and not just do it to lift a dependency.
Right. I will not merge my branch, but look into breaking the zope.app.publisher dependency.
(see elsewhere on the thread for a way to cut the dependency of zope.app.publication to zope.app.exception completely with little effort)
This (move the ISystemErrorView) seems to be the right solution to get rid of the zope.app.publication dependency on zope.app.exception. In a project of mine I need zope.app.exception independently of this dependency but I do not want to depend on zope.formlib for a little feature of it which can be done by another smaller package.
I looked into it, its not a project of mine it's z3c.layer.pagelet but it can be refactored to use only the ISystemErrorView interface. It uses some classes from zope.app.exception but does not need their features. So I'll refactor it.
I understand. Why not move the namedtemplate mechanism somewhere else entirely, though? This way we'd not introduce new code. The namedtemplate code itself only seems to depend on zope.traversing, but that doesn't sound like a good home. The tests depend on zope.app.pagetemplate, so perhaps it should move there? This is still a dependency of zope.app.exception anyway, and it itself doesn't appear to depend on zope.formlib.
Nice idea. I'll look into it.
zope.app.exception's UI bits are a curious case in that they're not really part of the ZMI, though they integrate with the ZMI and assume the existence of some macros. It's also a zope.app.* package and we'd like to get rid of those in the toolkit. What to do with it?
Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Michael Howitz wrote:
Am 14.05.2009 um 15:02 schrieb Martijn Faassen: psnip]
Is this replacement compatible with zope.formlib's namedtemplate mechanism? Will anything break?
No it is not compatible. So I think it's a bad idea.
Ah, all right, glad we agree.
Breaking the dependency between zope.app.publication and zope.app.exception by moving the ISystemErrorView interface and maybe the class which implements it to zope.browser would be better. I'll look into it at weekend.
Thanks! [snip]
I understand. Why not move the namedtemplate mechanism somewhere else entirely, though? This way we'd not introduce new code. The namedtemplate code itself only seems to depend on zope.traversing, but that doesn't sound like a good home. The tests depend on zope.app.pagetemplate, so perhaps it should move there? This is still a dependency of zope.app.exception anyway, and it itself doesn't appear to depend on zope.formlib.
Nice idea. I'll look into it.
Cool. It would seem to make sense that the named template mechanism is bundled along with the page template library anyway (instead of the form library). zope.formlib currently depends on zope.app.pagetemplate too so we could easily leave a backwards compatibility import in place. zope.app.pagetemplate might be worth our further attention later, but this at least would clean up a bit more mess as a first step. Regards, Martijn
Am 15.05.2009 um 13:30 schrieb Martijn Faassen: [...]
Cool. It would seem to make sense that the named template mechanism is bundled along with the page template library anyway (instead of the form library). zope.formlib currently depends on zope.app.pagetemplate too so we could easily leave a backwards compatibility import in place.
Done. Moved namedtemplate to zope.app.pagetemplate and made new releases of zope.app.pagetemplate zope.formlib Also cut the dependency of zope.app.publication on zope.app.exception by moving ISystemErrorView to zope.browser. Released: zope.browser zope.app.exception zope.app.publication Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Michael Howitz wrote:
Am 15.05.2009 um 13:30 schrieb Martijn Faassen: [...]
Cool. It would seem to make sense that the named template mechanism is bundled along with the page template library anyway (instead of the form library). zope.formlib currently depends on zope.app.pagetemplate too so we could easily leave a backwards compatibility import in place.
Done. Moved namedtemplate to zope.app.pagetemplate and made new releases of zope.app.pagetemplate zope.formlib
Also cut the dependency of zope.app.publication on zope.app.exception by moving ISystemErrorView to zope.browser. Released: zope.browser zope.app.exception zope.app.publication
Very cool, thanks very much for doing this work! Looking at the new dependency cycle graphs again. This is the before: http://startifact.com/depgraphs/zope_app_publisher_cycles.svg And this is the after: http://startifact.com/depgraphs/zope_app_publisher_cycles2.svg zope.app.exception is now taken from the graph (good!) Somehow a direct cyclical dependency between zope.app.publication and zope.app.publication now exists where there wasn't any before. zope.app.publication now depends on zope.app.publisher and it didn't do so in the past. Ah, it looks like this was actually a missing dependency which got added about 6 weeks ago. We need to get rid of it... Let's continue with the other refactoring: It looks like we still need to lose the dependency of zope.app.publisher on zope.app.component, or alternatively (or in addition) lose the dependency on zope.app.component on zope.formlib and zope.app.security. The zope.app.security dependency turns out to be only a test dependency, so I just made it such. zope.app.component is starting to look pretty empty. I can see three things still going on in it: * some browser views in zope.app.component.browser. These are to support the ZMI and can stay where they are. * the registration of the zope:view and zope:resource directives. I'm not sure what these are for, as we have browser:view and browser:resource. Perhaps these can be safely lifted into zope.app.publisher, which defines the browser:* varieties * the code in zope.app.component vocabularies. This is support code to create vocabularies for utilities. It depends on zope.interface, zope.component and zope.schema, and zope.app.interface. It might be sensible to move this vocabulary stuff (along with the one in zope.app.interface that we depend on) into a package called zope.componentvocabulary. We can jettison zope.app.component then. zope.componentvocabulary would depend on zope.schema, zope.component, zope.interface and zope.security only. We can then make zope.app.publisher depend on zope.componentvocabulary and lose the zope.formlib dependency, along with the zope.app.security dependency. Anyone wants to work on zope.componentvocabulary? It'd contain zope.app.component.vocabulary + surrounding tests, and zope.app.interface's vocabulary that it depends on. Regards, Martijn
On Tuesday 19 May 2009, Martijn Faassen wrote:
* the registration of the zope:view and zope:resource directives. I'm not sure what these are for, as we have browser:view and browser:resource. Perhaps these can be safely lifted into zope.app.publisher, which defines the browser:* varieties
Yes. The zope:* variants are used to allow registration of non-browser views and resources. I am pretty sure it is still used, so we should keep them, but the move to zope.app.publisher makes sense.
* the code in zope.app.component vocabularies. This is support code to create vocabularies for utilities. It depends on zope.interface, zope.component and zope.schema, and zope.app.interface.
It might be sensible to move this vocabulary stuff (along with the one in zope.app.interface that we depend on) into a package called zope.componentvocabulary. We can jettison zope.app.component then. zope.componentvocabulary would depend on zope.schema, zope.component, zope.interface and zope.security only.
We can then make zope.app.publisher depend on zope.componentvocabulary and lose the zope.formlib dependency, along with the zope.app.security dependency.
I agree. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
Hi there, I started working on zope.componentvocabulary. It exists now and zope.app.interface and zope.app.component both depend on it, along with zope.app.publisher. We're not entirely rid of zope.app.component yet though: Martijn Faassen wrote: [snip]
* the registration of the zope:view and zope:resource directives. I'm not sure what these are for, as we have browser:view and browser:resource. Perhaps these can be safely lifted into zope.app.publisher, which defines the browser:* varieties
I need to do some analysis to see where the "zope:view" and "zope:resource" directives are in use. I don't want to accidentally introduce *more* dependencies as packages that use these directives would now have to depend on zope.app.publisher instead of zope.app.component, and zope.app.publisher carries around a load of dependencies. Regards, Martijn
Hey,
I need to do some analysis to see where the "zope:view" and "zope:resource" directives are in use. I don't want to accidentally introduce *more* dependencies as packages that use these directives would now have to depend on zope.app.publisher instead of zope.app.component, and zope.app.publisher carries around a load of dependencies.
I wrote a quick script that uses lxml to parse a whole lot of *.zcml files. I find that these directives are in use in the following places: zope.app.preference/src/zope/app/preference/configure.zcml zope.app.apidoc/src/zope/app/apidoc/codemodule/browser/introspector.zcml zope.app.apidoc/src/zope/app/apidoc/enabled.zcml zope.app.apidoc/src/zope/app/apidoc/disabled.zcml zope.app.publisher/src/zope/app/publisher/xmlrpc/configure.zcml zope.traversing/src/zope/traversing/browser/configure.zcml zope.html/src/zope/html/configure.zcml zope.app.form/src/zope/app/form/browser/tests/widgetDirectives.zcml zope.app.securitypolicy/src/zope/app/securitypolicy/browser/configure.zcml zope.app.http/src/zope/app/http/exception/configure.zcml zope.app.http/src/zope/app/http/configure.zcml zope.app.onlinehelp/src/zope/app/onlinehelp/configure.zcml zope.app.ftp/src/zope/app/ftp/configure.zcml zope.app.dav/src/zope/app/dav/configure.zcml zope.mimetype/src/zope/mimetype/configure.zcml The zope.traversing dependency is a problem today, as I don't think zope.app.component is currently a dependency of this package. It sets up various IAbsoluteURL views. It might actually be the best to move these ZCML directives *down* into zope.component. That won't affect the dependencies of zope.component at all in fact; the [zcml] dependencies of zope.component already need all the dependencies that zope.app.component's view and resource directives implement. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
It might actually be the best to move these ZCML directives *down* into zope.component. That won't affect the dependencies of zope.component at all in fact; the [zcml] dependencies of zope.component already need all the dependencies that zope.app.component's view and resource directives implement.
+1 to that move. 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 iD8DBQFKFAr++gerLs4ltQ4RAh1WAJ9Sw2mdwfCtTLbwqxk3mm+Uik8SUQCfb0gh y+5GZqgBGlWDo9ZLDYwoHC4= =zJUv -----END PGP SIGNATURE-----
Martijn Faassen wrote:
It might actually be the best to move these ZCML directives *down* into zope.component. That won't affect the dependencies of zope.component at all in fact; the [zcml] dependencies of zope.component already need all the dependencies that zope.app.component's view and resource directives implement.
I see that zope.component now relies fairly heavily on the setuptools "extras_require", which makes the proposed move possible. At what point did we decide extras_require is good? Just curious. Shane
Previously Shane Hathaway wrote:
Martijn Faassen wrote:
It might actually be the best to move these ZCML directives *down* into zope.component. That won't affect the dependencies of zope.component at all in fact; the [zcml] dependencies of zope.component already need all the dependencies that zope.app.component's view and resource directives implement.
I see that zope.component now relies fairly heavily on the setuptools "extras_require", which makes the proposed move possible. At what point did we decide extras_require is good? Just curious.
I think it was grandfathered in. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Shane Hathaway wrote:
Martijn Faassen wrote:
It might actually be the best to move these ZCML directives *down* into zope.component. That won't affect the dependencies of zope.component at all in fact; the [zcml] dependencies of zope.component already need all the dependencies that zope.app.component's view and resource directives implement.
I see that zope.component now relies fairly heavily on the setuptools "extras_require", which makes the proposed move possible. At what point did we decide extras_require is good? Just curious.
We didn't. This extras_requires has been in there for a long time, as the other ZCML statements are already defined in it. In the past I proposed pulling out the ZCML statement implementations from zope.component into something like zope.componentzcml, or zcml.component or whatnot. That could still happen, if we can find some consensus. Regards, Martijn
Hi there, Michael Howitz wrote:
z3c.template is used there instead of zope.formlib.
I can merge this branch in the next days and cut a release.
I'm worried by the amount of *new* code that is pulled in just to reduce a dependency. Making this change would pull in *more* dependencies, not less! Not only do we pull in z3c.template, this package also pulls in z3c.ptcompat, which in turn needs extras to actually work. As Roger says this is a compatibility layer, and that isn't pretty either. We shouldn't pull in new code to reduce dependencies. Any new code added into the Zope Toolkit and that shouldn't be done without a discussion (and not done as a minor dependency refactoring). zope.app.exception defines views that pull in standard_macros. I'm not sure the Zope Toolkit should be concerned with views at all at this stage. I'd like to consider moving the whole page template story off into its own area at some point that is not core to the Toolkit, so it's easy to use other templating systems. The only reason zope.app.publication appears to be depending on zope.app.exception is because it needs ISystemErrorView. It's used once somewhere deep within complex exception handling code. I propose we move ISystemErrorView from zope.app.exception into zope.browser, hopefully cutting zope.app.exception out of the dependency tree entirely. Regards, Martijn
On 5/13/09 1:55 PM, Martijn Faassen wrote:
Hi there,
zope.app.publisher is depended on by quite a bit of code that uses the Zope Toolkit, as it defines brower:view and browser:resource and the like.
Unfortunately zope.app.publisher currently depends on more than 60 packages. This is rather excessive, and we'd like to cut down on this.
Also interesting about zope.app.publisher is that while it defines a 'browser' directory it actually doesn't contain any ZMI code; instead ZCML directives are defined there. Refactoring so the ZMI isn't around anymore is usually a good first step, but that's not needed here.
If you look at the dependency graph for zope.app.publisher the task of fixing this looks daunting:
http://startifact.com/depgraphs/zope.app.publisher.svg
But now please observe the following:
http://startifact.com/depgraphs/zope_app_publisher_cycles.svg
This identifies the main cycles in that dependency graph. If we break those in the right way, we can cut down a lot of dependencies in one go. Getting rid of the zope.app.form and zope.formlib dependencies looks like a sensible step.
From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are):
* cut the dependency of zope.app.publisher on zope.app.component
* OR cut the dependency of zope.app.component on zope.formlib
* cut the dependency of zope.app.publisher on zope.app.publication
* OR cut the dependency of zope.app.component on zope.app.security
* cut the dependency of zope.app.publisher on zope.app.publication
* OR cut the dependency of zope.app.publication on zope.app.exception
* OR cut the dependency of zope.app.exception on zope.formlib
There are probably a few more options there, but given that small graph, you get the picture.
Any volunteers to do this research on how hard some of these steps would look and report back here? Once we've discussed the options we can proceed fixing the problem.
I did a bit of research on the direct "zope.app.*" dependencies of zope.formlib. - I was able to get rid of a dependency on zope.app.container by requiring zope.browser>=1.1 (which Tres released yesterday); this package now has the ``IAdding`` interface that zope.formlib relies upon. - I looked into its dependency on zope.app.pagetemplate. It defines two "named templates" in its form.py module using The ViewPageTemplateFile class from zope.app.pagetemplate. Each is registered in its configure.zcml as adapter with the name "default". I don't have enough zen to know what the intent is here or whether the named templates could use zope.pagetemplate instead. - I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere "neutral" would break this particular dependency. - C
Chris McDonough wrote:
I did a bit of research on the direct "zope.app.*" dependencies of zope.formlib.
- I looked into its dependency on zope.app.pagetemplate. It defines two "named templates" in its form.py module using The ViewPageTemplateFile class from zope.app.pagetemplate. Each is registered in its configure.zcml as adapter with the name "default". I don't have enough zen to know what the intent is here or whether the named templates could use zope.pagetemplate instead.
This is part of the whole named template adapter story. The rationale for the whole story is to be able to replace the template of a view without touching the view. So the template is looked up as an adapter and not just accessed as self.index / self.template. Personally I find the whole feature just annoying and overcomplicated. I think the whole feature is due for removal. It's only used in a very minor number of cases and not consistently with views in general.
- I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere "neutral" would break this particular dependency.
Why not move the interfaces to zope.formlib and invert the dependency, so zope.app.form depends on zope.formlib? Or are these generally useful outside of a formlib context? Hanno
On 5/14/09 6:36 PM, Hanno Schlichting wrote:
Chris McDonough wrote:
I did a bit of research on the direct "zope.app.*" dependencies of zope.formlib.
- I looked into its dependency on zope.app.pagetemplate. It defines two "named templates" in its form.py module using The ViewPageTemplateFile class from zope.app.pagetemplate. Each is registered in its configure.zcml as adapter with the name "default". I don't have enough zen to know what the intent is here or whether the named templates could use zope.pagetemplate instead.
This is part of the whole named template adapter story. The rationale for the whole story is to be able to replace the template of a view without touching the view. So the template is looked up as an adapter and not just accessed as self.index / self.template. Personally I find the whole feature just annoying and overcomplicated. I think the whole feature is due for removal. It's only used in a very minor number of cases and not consistently with views in general.
- I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere "neutral" would break this particular dependency.
Why not move the interfaces to zope.formlib and invert the dependency, so zope.app.form depends on zope.formlib? Or are these generally useful outside of a formlib context?
That's possible. A Google search indicates that zope.app.form.interfaces is being used by: - zope.formlib - schooltool - plone (maybe) - alchemist - sputnik (an openplans project) - collective.easyslider - zc.extjs - zenoss - alphaflow It's also apparently documented in Phillip's book. So... what? Errrr... I dunno. The interfaces are: from zope.app.form.interfaces import IInputWidget, IDisplayWidget from zope.app.form.interfaces import InputErrors, WidgetInputError from zope.app.form.browser.interfaces import IWidgetImportErrorView Any thoughts? - C
Hey, Chris McDonough wrote: [snip a lot of places where these interfaces are used] I'm sure these interfaces are used all over the place as they're used to help implement widgets; we can't just remove them from their original location, but...
It's also apparently documented in Phillip's book. So... what? Errrr... I dunno. The interfaces are:
from zope.app.form.interfaces import IInputWidget, IDisplayWidget from zope.app.form.interfaces import InputErrors, WidgetInputError from zope.app.form.browser.interfaces import IWidgetImportErrorView
Any thoughts?
What would happen if we moved them to zope.formlib and left backwards compatibility imports in place in zope.app.formlib? I think it makes sense for zope.formlib to specify its widget interfaces, and zope.app.form to implement a bunch of those widgets. We can also consider (possibly as a separate later step) moving at least some widget implementations themselves into zope.formlib and just leave the old ZCML form stuff behind in zope.app.form (and a lot of backward compat code). We should only move those things into zope.formlib that don't increase its dependencies though, so we can't move everything. Regards, Martijn
Hey, Hanno Schlichting wrote:
This is part of the whole named template adapter story. The rationale for the whole story is to be able to replace the template of a view without touching the view. So the template is looked up as an adapter and not just accessed as self.index / self.template. Personally I find the whole feature just annoying and overcomplicated. I think the whole feature is due for removal. It's only used in a very minor number of cases and not consistently with views in general.
Could you comment on the discussion I've had with Michael Howitz elsewhere in this thread about this then? I think this relates to the whole z3c.template and zope.formlib discussion. [suggestion to invert the dependency between zope.formlib and zope.app.form] Ah, great minds... Regards, Martijn
On 5/14/09 6:09 PM, Chris McDonough wrote:
On 5/13/09 1:55 PM, Martijn Faassen wrote:
Hi there,
zope.app.publisher is depended on by quite a bit of code that uses the Zope Toolkit, as it defines brower:view and browser:resource and the like.
Unfortunately zope.app.publisher currently depends on more than 60 packages. This is rather excessive, and we'd like to cut down on this.
Also interesting about zope.app.publisher is that while it defines a 'browser' directory it actually doesn't contain any ZMI code; instead ZCML directives are defined there. Refactoring so the ZMI isn't around anymore is usually a good first step, but that's not needed here.
If you look at the dependency graph for zope.app.publisher the task of fixing this looks daunting:
http://startifact.com/depgraphs/zope.app.publisher.svg
But now please observe the following:
http://startifact.com/depgraphs/zope_app_publisher_cycles.svg
This identifies the main cycles in that dependency graph. If we break those in the right way, we can cut down a lot of dependencies in one go. Getting rid of the zope.app.form and zope.formlib dependencies looks like a sensible step.
From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are):
* cut the dependency of zope.app.publisher on zope.app.component
* OR cut the dependency of zope.app.component on zope.formlib
* cut the dependency of zope.app.publisher on zope.app.publication
* OR cut the dependency of zope.app.component on zope.app.security
* cut the dependency of zope.app.publisher on zope.app.publication
* OR cut the dependency of zope.app.publication on zope.app.exception
* OR cut the dependency of zope.app.exception on zope.formlib
There are probably a few more options there, but given that small graph, you get the picture.
Any volunteers to do this research on how hard some of these steps would look and report back here? Once we've discussed the options we can proceed fixing the problem.
I did a bit of research on the direct "zope.app.*" dependencies of zope.formlib.
- I was able to get rid of a dependency on zope.app.container by requiring zope.browser>=1.1 (which Tres released yesterday); this package now has the ``IAdding`` interface that zope.formlib relies upon.
- I looked into its dependency on zope.app.pagetemplate. It defines two "named templates" in its form.py module using The ViewPageTemplateFile class from zope.app.pagetemplate. Each is registered in its configure.zcml as adapter with the name "default". I don't have enough zen to know what the intent is here or whether the named templates could use zope.pagetemplate instead.
- I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere "neutral" would break this particular dependency.
- C
Wrt a possible future for zope.catalog, I think we might leave it be, and encourage framework writers to use repoze.catalog instead. For instance, a new "zope.app.catalog" package could be written that depends on repoze.catalog. repoze.catalog is a ZODB catalog implementation inspired by zope.catalog. It uses zope.index subclasses for its index implementations. It has a direct dependency on zope.index; that is actually its only direct dependency. (although zope.index depends on ZODB, so that obviously gets pulled down too when you install it, plus its transitives). The trick it uses to avoid inappropriate dependencies is to make the framework writer register event subscribers for IObjectModifiedEvent and its the framework's equivalent of "IIntIdRemovedEvent", etc instead of providing the handlers itself. A framework developer could wrap repoze.catalog in such a way that these things happened like they do in zope.catalog; just register appropriate subscribers. It also returns sets of integer docids rather than a "result set" that knows innately how to resolve these integer ids. A framework developer could obviously create a subclass or adapter that wrapped the catalog and did the object resolution. http://svn.repoze.org/repoze.catalog/trunk/ - C
Hey, Chris McDonough wrote:
I did a bit of research on the direct "zope.app.*" dependencies of zope.formlib.
Cool!
- I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere "neutral" would break this particular dependency.
I think it might make sense to reverse these dependencies - i.e. zope.app.form uses interfaces from zope.formlib for implementing its widgets. The old ZCML-based form mechanism in zope.app.form is moribund anyway so we can just ignore that. Don't know whether this would help the dependency structures though. I think it's going to be hard to motivate moving zope.app.form interfaces to zope.browser, as ideally we'd like to make the rest of the toolkit unaffected by particular decisions on how form generation should work. Regards, Martijn
On 5/15/09 7:00 AM, Martijn Faassen wrote:
Hey,
Chris McDonough wrote:
I did a bit of research on the direct "zope.app.*" dependencies of zope.formlib.
Cool!
- I looked into its dependency on zope.app.form. It essentially uses a bunch of interfaces from the zope.app.form.interfaces package. I don't know whether it would be reasonable to move all those interfaces to zope.browser or somewhere else, but essentially moving those interfaces to somewhere "neutral" would break this particular dependency.
I think it might make sense to reverse these dependencies - i.e. zope.app.form uses interfaces from zope.formlib for implementing its widgets. The old ZCML-based form mechanism in zope.app.form is moribund anyway so we can just ignore that. Don't know whether this would help the dependency structures though.
I tried to go after this today (reversing the dependency setup between zope.formlib and zope.app.form). There are hundreds of changes that need to be made to move interfaces to zope.formlib. I made them (more or less mechanically) but then couldn't get the tests to pass. Since I don't actually use zope.formlib, I don't think it's appropriate that I commit anything. OTOH, I'm pretty convinced that this action would be a win for packages that depend on formlib. I found these: ./zope.app.component-3.7.0-py2.5.egg/EGG-INFO/requires.txt:zope.formlib ./zope.app.exception-3.5.0-py2.5.egg/EGG-INFO/requires.txt:zope.formlib ./zope.app.zcmlfiles-3.5.3-py2.5.egg/EGG-INFO/requires.txt:zope.formlib Are we done yet? ;-) - C
Chris McDonough wrote:
I tried to go after this today (reversing the dependency setup between zope.formlib and zope.app.form). There are hundreds of changes that need to be made to move interfaces to zope.formlib. I made them (more or less mechanically) but then couldn't get the tests to pass. Since I don't actually use zope.formlib, I don't think it's appropriate that I commit anything.
How about you commit it to a branch and let others help you? This particular dependency has annoyed at least me quite a bit ;) Hanno
Hey, Chris McDonough wrote: [snip]
I tried to go after this today (reversing the dependency setup between zope.formlib and zope.app.form). There are hundreds of changes that need to be made to move interfaces to zope.formlib. I made them (more or less mechanically) but then couldn't get the tests to pass. Since I don't actually use zope.formlib, I don't think it's appropriate that I commit anything.
All right, thanks for trying. Hopefully someone else can take a look at it at some point.
OTOH, I'm pretty convinced that this action would be a win for packages that depend on formlib. I found these:
./zope.app.component-3.7.0-py2.5.egg/EGG-INFO/requires.txt:zope.formlib ./zope.app.exception-3.5.0-py2.5.egg/EGG-INFO/requires.txt:zope.formlib ./zope.app.zcmlfiles-3.5.3-py2.5.egg/EGG-INFO/requires.txt:zope.formlib
With the recent changes zope.app.component is almost devoid of code and packages that relied on zope.app.component now can rely on other packages and entirely avoid the zope.formlib dependency. zope.app.exception only depended on formlib's namedtemplate facility which now resides in zope.app.pagetemplate instead. zope.app.zcmlfiles is a scary package that just pulls in a lot of ZCML that hopefully can vanish entirely over time. Regards, Martijn
participants (9)
-
Chris McDonough -
Hanno Schlichting -
Martijn Faassen -
Michael Howitz -
Roger Ineichen -
Shane Hathaway -
Stephan Richter -
Tres Seaver -
Wichert Akkerman