Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
-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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 · m...@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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 · m...@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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 · m...@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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 · m...@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 ___ 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 )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
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 ___ 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 )
