Dependencies on zope.app.appsetup
Hi there. One of most annoying dependencies is the "zope.app.appsetup" package. Some packages, like zope.session depend on it just to provide "boostrap setup" for using these packages in context of "zope3, the application server", however, they can be greatly used without it, so this is really awful dependency. I saw that, on last sprint, the subscriber for error reporting utility was moved from zope.error to zope.app.appsetup, so zope.error could lose the dependency on zope.app.appsetup. So, the first question is: do we want to move all subscribers like that? It doesn't seem like a best solution though, because then zope.app.appsetup should depend on all those packages, like zope.session. :-/ The problem is that the bootstrap code in zope.app.appsetup is really "zope3, the application"-specific, so it uses "root folders", persistent site managers, site management containers, ZopePublication.root_name, and so on. The code itself is okay, because it provides an easy way to setup misc. components for the "zope3 application server", but still it's a problem, because it's probably impossible to refactor it in a application-independent way (until we provide some cool pluggable application bootstrapping mechanism, which is probably will become too complex and not needed/used by most application developers). So, the general question is where should we move the bootstrap setup code? Or, alternatively, we could just leave it in place, but greatly separate it from another package components and provide zope.app.appsetup as an "extra" dependency (sigh...). Ideas? -- WBR, Dan Korostelev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Korostelev wrote:
Hi there.
One of most annoying dependencies is the "zope.app.appsetup" package. Some packages, like zope.session depend on it just to provide "boostrap setup" for using these packages in context of "zope3, the application server", however, they can be greatly used without it, so this is really awful dependency.
I saw that, on last sprint, the subscriber for error reporting utility was moved from zope.error to zope.app.appsetup, so zope.error could lose the dependency on zope.app.appsetup. So, the first question is: do we want to move all subscribers like that? It doesn't seem like a best solution though, because then zope.app.appsetup should depend on all those packages, like zope.session. :-/
Making the "application" depend on the "libraries" is fine, and the name of the package ('appsetup') suggests that it *should* be the place with all the dependencies: OO frameworks need to have *somebody* wire in the pieces, and that bit is usually the part which runs at startup.
The problem is that the bootstrap code in zope.app.appsetup is really "zope3, the application"-specific, so it uses "root folders", persistent site managers, site management containers, ZopePublication.root_name, and so on. The code itself is okay, because it provides an easy way to setup misc. components for the "zope3 application server", but still it's a problem, because it's probably impossible to refactor it in a application-independent way (until we provide some cool pluggable application bootstrapping mechanism, which is probably will become too complex and not needed/used by most application developers).
So, the general question is where should we move the bootstrap setup code? Or, alternatively, we could just leave it in place, but greatly separate it from another package components and provide zope.app.appsetup as an "extra" dependency (sigh...).
+1 for moving all that stuff into the application. 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 iD8DBQFJvT/E+gerLs4ltQ4RAg3GAJ9+ns3Vos2k3nwLsfJywxYwcrWKuQCgphjG MyH570P+c4JoxhuNBEUDc7k= =ePCM -----END PGP SIGNATURE-----
Hey Dan, You bring up another great topic! Dan Korostelev wrote:
One of most annoying dependencies is the "zope.app.appsetup" package. Some packages, like zope.session depend on it just to provide "boostrap setup" for using these packages in context of "zope3, the application server", however, they can be greatly used without it, so this is really awful dependency.
I saw that, on last sprint, the subscriber for error reporting utility was moved from zope.error to zope.app.appsetup, so zope.error could lose the dependency on zope.app.appsetup. So, the first question is: do we want to move all subscribers like that? It doesn't seem like a best solution though, because then zope.app.appsetup should depend on all those packages, like zope.session. :-/
We did run this into this issue at the last sprint. We analyzed cycles in package dependencies and decided this was a way to break these dependencies. I think it's less bad that zope.app.appsetup depends on a lot of dependencies than for zope.session to do so, at least if nothing much actually depends on zope.app.appsetup. After all, something setting up Zope 3 the application server will of course have to include a lot of packages...
The problem is that the bootstrap code in zope.app.appsetup is really "zope3, the application"-specific, so it uses "root folders", persistent site managers, site management containers, ZopePublication.root_name, and so on. The code itself is okay, because it provides an easy way to setup misc. components for the "zope3 application server", but still it's a problem, because it's probably impossible to refactor it in a application-independent way (until we provide some cool pluggable application bootstrapping mechanism, which is probably will become too complex and not needed/used by most application developers).
While it might be too complex for most application developers it might not be too complex for framework developers that use the Zope Framework as a base. I think such an infrastructure might arise if the Zope 3 and Grok and Zope 2 developers sit together one day. But not today. :)
So, the general question is where should we move the bootstrap setup code? Or, alternatively, we could just leave it in place, but greatly separate it from another package components and provide zope.app.appsetup as an "extra" dependency (sigh...).
I think your question ties into the need for some packages to depend on zope.app.appsetup? Does zope.session really need this stuff? Can't we just get rid of that need? Regards, Martijn
On Monday 16 March 2009, Martijn Faassen wrote:
I saw that, on last sprint, the subscriber for error reporting utility was moved from zope.error to zope.app.appsetup, so zope.error could lose the dependency on zope.app.appsetup. So, the first question is: do we want to move all subscribers like that? It doesn't seem like a best solution though, because then zope.app.appsetup should depend on all those packages, like zope.session. :-/
We did run this into this issue at the last sprint. We analyzed cycles in package dependencies and decided this was a way to break these dependencies.
I think it's less bad that zope.app.appsetup depends on a lot of dependencies than for zope.session to do so, at least if nothing much actually depends on zope.app.appsetup. After all, something setting up Zope 3 the application server will of course have to include a lot of packages...
BTW, +1. zope.app.appsetup being a little bit of an all toppings pizza is okay. It's job is to wire things up. In zome respect it represents a basic Zope 3 app setup. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
participants (4)
-
Dan Korostelev -
Martijn Faassen -
Stephan Richter -
Tres Seaver