Zope Toolkit - packages with zope.app dependencies
Hi. I allowed myself to work on the Zope Toolkit over x-mas and make some decisions to get some progress ;-) The good news is that all our herculean efforts to unclutter the dependency structures have really payed off. Only very few zope.* packages still have dependencies on zope.app packages. I excluded those misbehaving packages from the ZTK to reflect this and noted them in a "unresolved-dependencies" option. The ZTK no longer contains any zope.app packages with one exception. There's a number of problematic packages, where I'd like some other opinions on how to proceed. zope.traversing It has a dependency on zope.app.publication. Given the central role of zope.traversing I allowed it and zope.app.publication to stay in the ZTK, but moved it to the under-review option. We have talked about refactoring the traversal and publication story in the past, without seeing any consensus on how to move forward with it. My feeling tells me, that a pure renaming of zope.app.publication to zope.publication or similar code reshuffling into other packages isn't really helpful in this case. ACTION: Until we see further progress on clarifying the semantics of traversal and publication, I'd leave zope.app.publication in the ZTK. zope.catalog and zope.intid Both of these have a dependency on zope.app.testing. Their tests heavily rely on a functional test setup with a ZODB and persistent data. They don't seem to need a publisher or a web server, though. ACTION: Remove them from the ZTK. Once their test setup no longer relies on zope.app.testing, they should move back into the ZTK. zope.file I think this package is just misnamed and should have been zope.app.file. It's a full blown content type implementation, with dependencies on zope.app.form, providing browser view code, browser menus and quite a bit of zope.app integration. It's test setup needs a full blown ZODB and publisher environment. ACTION: I'd remove this from the ZTK until someone is willing to refactor it to provide a minimal file implementation. zope.formlib and friends zope.formlib depends on zope.app.form which in turn depends on many zope.app packages. zope.html and zope.mimetype both depend on zope.formlib or zope.app.form. Various people myself included looked at the zope.formlib / zope.app.form split to see if it can be refactored in a sensible way. I think the conclusion has so far been: there's just no way. There isn't a sensible set of basic principles or interfaces in formlib, that can form a base for a higher level zope.app.form. All the packages using formlib today actually make use of the widgets in zope.app.form and thus basically on the entire functionality. With z3c.form we have another independent form library from the Zope community, which has seen at least as widespread if not more adoption. Preferring one over the other doesn't make much sense to me. ACTION: At this point I'd suggest to drop zope.formlib, zope.app.form and packages that depend on it from the ZTK. zope.testbrowser This package offers functional browser tests and consequently needs a way to set up a ZODB and publisher with some default application configuration. I don't see how this can be achieved without depending on a specific application environment like zope.app.appsetup or Zope2/App. Zope2 depends on the package and it makes sense to include it on the application server level - but not on a toolkit level for building frameworks. ACTION: I'd suggest to drop this package from the ZTK. Merry x-mas :) Hanno
Hanno Schlichting wrote:
It has a dependency on zope.app.publication. Given the central role of zope.traversing I allowed it and zope.app.publication to stay in the ZTK, but moved it to the under-review option.
On the zope.traversing trunk, I have removed the zope.app.publication dependency. It was only a testing dependency.
We have talked about refactoring the traversal and publication story in the past, without seeing any consensus on how to move forward with it. My feeling tells me, that a pure renaming of zope.app.publication to zope.publication or similar code reshuffling into other packages isn't really helpful in this case.
ACTION: Until we see further progress on clarifying the semantics of traversal and publication, I'd leave zope.app.publication in the ZTK.
What other ZTK packages depend on zope.app.publication? zope.app.publication is an extra layer of complexity that most sites could probably do without. Shane
On Sun, Dec 27, 2009 at 8:12 AM, Shane Hathaway <shane@hathawaymix.org> wrote:
Hanno Schlichting wrote:
It has a dependency on zope.app.publication. Given the central role of zope.traversing I allowed it and zope.app.publication to stay in the ZTK, but moved it to the under-review option.
On the zope.traversing trunk, I have removed the zope.app.publication dependency. It was only a testing dependency.
Great. It looked to me like there was an actual semantic dependency between the two packages.
What other ZTK packages depend on zope.app.publication? zope.app.publication is an extra layer of complexity that most sites could probably do without.
There's none. I released a new zope.traversing and updated the ZTK. It's now really app-free :) Thanks, Hanno
Hanno Schlichting wrote:
The ZTK no longer contains any zope.app packages with one exception.
I'm not sure I understand the details of what you did. I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult. Perhaps you mean the same thing? Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hanno Schlichting wrote:
The ZTK no longer contains any zope.app packages with one exception.
I'm not sure I understand the details of what you did.
I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult.
zope.app packages are still out there, but no longer part of the ZTK after Hanno's work: he has squished (or tricked others into doing it) all remaining dependencies within the ZTK packages on zope.app.*. I'm +sys.maxint on this change. We can't be "making peoples' life difficult" by removing zope.app.* from the ZTK, because *nobody has shipped code* which depends on the ZTK per se. Anybody with dependencies on those packages needs to extend their own configuration to include them. Hanno has been doing *more* grenade smothering by helping finish zope.app eradication in Zope2, as well. CMF is nearly zope.app free (one remaining testing dependency). 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks5LpUACgkQ+gerLs4ltQ5cYACfekIFzlrB6a2W/ISrY+ODhYIp u6sAn0AI1XAcKOIcArlaITVUXD/FGsR4 =Mnzb -----END PGP SIGNATURE-----
Hey, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martijn Faassen wrote:
Hanno Schlichting wrote:
The ZTK no longer contains any zope.app packages with one exception. I'm not sure I understand the details of what you did.
I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult.
zope.app packages are still out there, but no longer part of the ZTK after Hanno's work: he has squished (or tricked others into doing it) all remaining dependencies within the ZTK packages on zope.app.*. I'm +sys.maxint on this change.
I'm very aware of Hanno's efforts and I'm very happy with it, but a lot of people contributed to making this possible. The goal is a clean dependency tree, and "removing zope.app.*" is a sub-goal that a clean dependency tree makes possible.
We can't be "making peoples' life difficult" by removing zope.app.* from the ZTK, because *nobody has shipped code* which depends on the ZTK per se. Anybody with dependencies on those packages needs to extend their own configuration to include them. Hanno has been doing *more* grenade smothering by helping finish zope.app eradication in Zope2, as well. CMF is nearly zope.app free (one remaining testing dependency).
We have tons of code that needs to upgrade to the ZTK, as the ZTK is derived from Zope 3. Zope 3 contained a lot of extra packages and we've been shipping code of the exploded Zope 3 for a while. Take for instance upgrading an existing Grok-based app. While I'd like zope.app* to be removed as much as possible from those applications, we'll need to at least provide a compatibility set for a while. My idea is to maintain versions of the zope.app.* packages that are known to work together and work with the zope.* packages for the time being. If we don't maintain a set of versions that work together, we risk breaking things. It seems to be the route to least effort to do this maintenance in a special sub-category of the ZTK. At present time I know the steering group certainly doesn't have consensus on removing zope.app.*. I know Jim for one was quite adamant that zope.app.* remain part of the ZTK for the time being (unfortunately one discussion that I neglected to record in the ZTK decisions document). We can't just go and throw these out without a clear decision. Regards, Martijn
On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen <faassen@startifact.com> wrote:
Hanno Schlichting wrote:
The ZTK no longer contains any zope.app packages.
I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult.
I disagree. In my opinion it's not part of the job of the ZTK to provide backwards compatibility with Zope 3. The toolkit is not a replacement for all of Zope 3 and you cannot run a Zope 3 application even after following all the refactorings on the toolkit alone. If users of Zope 3 want an upgrade story, they need to get together and make a new Zope 3 release which is based on the ZTK. For Zope2 we have covered the upgrade story already. Zope 2.12 uses its own KGS, which includes the entire set of zope.app packages in compatible versions. Current Zope2 trunk aka 2.13 runs directly on the Zope Toolkit KGS and doesn't include any zope.app packages anymore. If you want to upgrade to 2.13 you will have to refactor your code to no longer rely on zope.app packages while using Zope 2.12. In the case of Zope2 this is possible, as we don't use the application server parts of Zope 3 at all. So all those zope.app.appserver, applicationcontrol, zcmlfiles parts that actually wire a couple of distinct libraries together into something that has a configured webserver, publisher, security setup. I don't know how this is done in Grok and how much it reuses application policies of Zope 3. On a more practical note, it's actually just not helpful to include version pins for any zope.app packages in the ztk.cfg. I can add any arbitrary set of version definitions there. Then run the test-ztk tests and all tests will always pass. Since the packages under tests don't include nor depend on any zope.app packages, their test result is independent of any zope.app version pins. If you want to ensure any kind of actual compatibility, you need to run the tests for a defined set of zope.app packages. If you want to ensure Zope 3 as a whole can work with the ZTK, you need to run the tests for all of Zope 3. But that's clearly not what the ZTK is about - it's *not* Zope 3.5. If you want to have some upgrade story for Grok, Grok needs to define which packages including which zope.app packages it cares about and define a KGS that makes sure things keep working. Hanno
Hanno Schlichting wrote:
On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen <faassen@startifact.com> wrote:
Hanno Schlichting wrote:
The ZTK no longer contains any zope.app packages. I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult.
I disagree. In my opinion it's not part of the job of the ZTK to provide backwards compatibility with Zope 3. The toolkit is not a replacement for all of Zope 3 and you cannot run a Zope 3 application even after following all the refactorings on the toolkit alone. If users of Zope 3 want an upgrade story, they need to get together and make a new Zope 3 release which is based on the ZTK.
Totally ignoring our community's responsibility towards backwards compatibility and delegating it to a mythical set of "Zope 3 maintainers" isn't an option at all. We need to provide an upgrade path from pre-ZTK applications to ZTK applications. This upgrade path can take the form of a set of versions of zope.app.* libraries that people can choose to install for backwards compatibility. We should maintain this set of versions as part of the ZTK's test regime at the very least, otherwise we'll inevitably break something.
For Zope2 we have covered the upgrade story already. Zope 2.12 uses its own KGS, which includes the entire set of zope.app packages in compatible versions.
Let's please please please maintain that set of zope.app.* packages centrally. Zope 2 isn't the only consumer of these packages.
On a more practical note, it's actually just not helpful to include version pins for any zope.app packages in the ztk.cfg. I can add any arbitrary set of version definitions there. Then run the test-ztk tests and all tests will always pass. Since the packages under tests don't include nor depend on any zope.app packages, their test result is independent of any zope.app version pins.
Then we certainly need to do more than version pins. We also need to test these packages. -1 to this change. I'm going to add the zope.app.* packages back to the ZTK until we've had a proper discussion about how, as a Zope community, we go forward with this. Delegating this responsibility *separately* to sub projects is just plain silly. Regards, Martijn
On 12/29/09 15:28 , Martijn Faassen wrote:
Hanno Schlichting wrote:
On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen <faassen@startifact.com> wrote:
Hanno Schlichting wrote:
The ZTK no longer contains any zope.app packages. I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult.
I disagree. In my opinion it's not part of the job of the ZTK to provide backwards compatibility with Zope 3. The toolkit is not a replacement for all of Zope 3 and you cannot run a Zope 3 application even after following all the refactorings on the toolkit alone. If users of Zope 3 want an upgrade story, they need to get together and make a new Zope 3 release which is based on the ZTK.
Totally ignoring our community's responsibility towards backwards compatibility and delegating it to a mythical set of "Zope 3 maintainers" isn't an option at all.
We need to provide an upgrade path from pre-ZTK applications to ZTK applications.
I don't know what you mean with pre-ZTK applications. Are those Zope 2 applications? Zope 3? Grok? All of those can keep working as long as Zope 2, Zope 3 and Grok make sure they keep working. Zope 2 has already done so. I saw that there is an effort for Grok as well. Zope 3 does not seem to have any maintainer at the moment, but I do not think it is fair to shift that responsibility to others by forcing zope.app.* into the ZTK. Wichert.
Wichert Akkerman wrote:
I don't know what you mean with pre-ZTK applications. Are those Zope 2 applications? Zope 3? Grok?
Yes, yes, yes. You know, us, who get together here on zope-dev to work together.
All of those can keep working as long as Zope 2, Zope 3 and Grok make sure they keep working.
That's us, here on zope-dev working together.
Zope 3 does not seem to have any maintainer at the moment
We're here on zope-dev to help maintain it.
but I do not think it is fair to shift that responsibility to others by forcing zope.app.* into the ZTK.
That's not what happened. What just happened that the responsibility was *forced out* of the ZTK. I'm all for taking away responsibility from the ZTK, but not just like that. Regards, Martijn
On 12/29/09 16:23 , Martijn Faassen wrote:
Wichert Akkerman wrote:
but I do not think it is fair to shift that responsibility to others by forcing zope.app.* into the ZTK.
That's not what happened. What just happened that the responsibility was *forced out* of the ZTK. I'm all for taking away responsibility from the ZTK, but not just like that.
I read this as 'the ZTK and Zope 3 are the same thing'. Is that what you are trying to say? Wichert.
Wichert Akkerman wrote:
On 12/29/09 16:23 , Martijn Faassen wrote:
Wichert Akkerman wrote:
but I do not think it is fair to shift that responsibility to others by forcing zope.app.* into the ZTK.
That's not what happened. What just happened that the responsibility was *forced out* of the ZTK. I'm all for taking away responsibility from the ZTK, but not just like that.
I read this as 'the ZTK and Zope 3 are the same thing'. Is that what you are trying to say?
No. I've argued strenuously against that notion in the past, in fact. I agree with the general idea of making the ZTK something much like the currently proposed set. I just don't like the execution. Like it or not, we can't just drop obligations to backwards compatibility just like that, and we should manage these responsibilities in common as much as we can. And then if we can responsibly lose these responsibilities, by all means. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hanno Schlichting wrote:
On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen <faassen@startifact.com> wrote:
Hanno Schlichting wrote:
The ZTK no longer contains any zope.app packages. I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult. I disagree. In my opinion it's not part of the job of the ZTK to provide backwards compatibility with Zope 3. The toolkit is not a replacement for all of Zope 3 and you cannot run a Zope 3 application even after following all the refactorings on the toolkit alone. If users of Zope 3 want an upgrade story, they need to get together and make a new Zope 3 release which is based on the ZTK.
Totally ignoring our community's responsibility towards backwards compatibility and delegating it to a mythical set of "Zope 3 maintainers" isn't an option at all.
The reality is that the zope.app.* packages don't fit the mission of the ZTK: they aren't widely-reusable libraries, but pieces of a particular appserver / framework. The other reality is that nobody is stepping up to do the work to maintain that appserver. There is *not* BBB issue with dropping those packagse from the ZTK, because everybody who is currently deployed with them has a valid way to use them *without* the ZTK. Pushing the burden of maintenance of those packages onto the ZTK, instaead of onto the portions of the community who use them, reduces the viability of the ZTK for almost no gain.
We need to provide an upgrade path from pre-ZTK applications to ZTK applications. This upgrade path can take the form of a set of versions of zope.app.* libraries that people can choose to install for backwards compatibility. We should maintain this set of versions as part of the ZTK's test regime at the very least, otherwise we'll inevitably break something.
Toolkits aren't frameworks or appservers: migration paths aren't part of their story: if you need a tool which doesn't come with the toolkit, you purchase it seaparately. If the tool *used* to come with the toolkit, and you still need it, you pull it out of the old toolkit and keep it on the side when you replace the toolkit. Defining those upgrade paths is the responsibility of the various groups consuming the (new) ZTK: in the case of Zope2, the Zope2 maintainers have chosen to do the work to remove all dependencies on zope.app.* packages from Zope2, leaving Zope2 free to use a zope-app-free ZTK without any issues.
For Zope2 we have covered the upgrade story already. Zope 2.12 uses its own KGS, which includes the entire set of zope.app packages in compatible versions.
Let's please please please maintain that set of zope.app.* packages centrally. Zope 2 isn't the only consumer of these packages.
What set? Why do you think that any given set of them is worth maintaining? Grok uses some subset of them, while a Zope3 app uses a bigger set, but Zope2 uses none: why is Grok's set (or Zope3's) important enough for the wider group of ZTK developers to care about?
On a more practical note, it's actually just not helpful to include version pins for any zope.app packages in the ztk.cfg. I can add any arbitrary set of version definitions there. Then run the test-ztk tests and all tests will always pass. Since the packages under tests don't include nor depend on any zope.app packages, their test result is independent of any zope.app version pins.
Then we certainly need to do more than version pins. We also need to test these packages.
-1 to this change. I'm going to add the zope.app.* packages back to the ZTK until we've had a proper discussion about how, as a Zope community, we go forward with this. Delegating this responsibility *separately* to sub projects is just plain silly.
You are treading on very dangerous ground here: commit wars are not a good way to solve this problem. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6cZcACgkQ+gerLs4ltQ79/gCgxBltITz0Rn9DEZxvwK2EleLQ np0An3vNmFWWGE2/OzSOLL+zTWA/mvrt =LFUf -----END PGP SIGNATURE-----
Tres Seaver wrote: [snip]
The reality is that the zope.app.* packages don't fit the mission of the ZTK: they aren't widely-reusable libraries, but pieces of a particular appserver / framework. The other reality is that nobody is stepping up to do the work to maintain that appserver.
I agree. But I'm not talking about maintaining the app server. I'm talking about helping people to move away from most of those packages, or otherwise find ways to maintain them.
There is *not* BBB issue with dropping those packagse from the ZTK, because everybody who is currently deployed with them has a valid way to use them *without* the ZTK. Pushing the burden of maintenance of those packages onto the ZTK, instaead of onto the portions of the community who use them, reduces the viability of the ZTK for almost no gain.
I think the ZTK developers have a responsibility to this use of the ZTK just like to anyone else's use. Just stopping to test whether all of this works with the ZTK isn't fulfilling our responsibility. [snip]
Defining those upgrade paths is the responsibility of the various groups consuming the (new) ZTK: in the case of Zope2, the Zope2 maintainers have chosen to do the work to remove all dependencies on zope.app.* packages from Zope2, leaving Zope2 free to use a zope-app-free ZTK without any issues.
Maintaining a coherent set of versions of zope.app.* packages is a responsibility that we can share in our community. Dropping this responsibility into a black hole by suddenly stopping to do so within the context of the ZTK is not the right way forward.
For Zope2 we have covered the upgrade story already. Zope 2.12 uses its own KGS, which includes the entire set of zope.app packages in compatible versions. Let's please please please maintain that set of zope.app.* packages centrally. Zope 2 isn't the only consumer of these packages.
What set? Why do you think that any given set of them is worth maintaining? Grok uses some subset of them, while a Zope3 app uses a bigger set, but Zope2 uses none: why is Grok's set (or Zope3's) important enough for the wider group of ZTK developers to care about?
Because we have a ton of installed base out there and we have a responsibility to maintain backwards compatibility. If some people don't care about that it's fine, but I expect at least some measure of cooperation with those who do.
-1 to this change. I'm going to add the zope.app.* packages back to the ZTK until we've had a proper discussion about how, as a Zope community, we go forward with this. Delegating this responsibility *separately* to sub projects is just plain silly.
You are treading on very dangerous ground here: commit wars are not a good way to solve this problem.
Sure. Unilaterally removing a huge amount of packages from a shared KGS is also not a good way to solve this problem. Regards, Martijn
On Tue, Dec 29, 2009 at 22:54, Martijn Faassen <faassen@startifact.com> wrote:
Because we have a ton of installed base out there
Do we? I think the debate is somewhat confused here, or possibly it's only me. :) It seems to be two separate issues here: 1. Including these packages in the ZTK. 2. Refactoring with BBB and deprecation. The last thing is obviously important, because these packages are, as you say, out there. But that really isn't very relevant to whether they are included in the ZTK or not. Because the ZTK does *not* have a big installed base. Zope 2.12 doesn't use it. Grok 1.0 doesn't use it. Zope 3.4 doesn't use it. So obviously the refactored zope.app.* packages should have BBB imports and stuff. I think everyone agrees about that. But does that mean these packages must be included in ZTK for the time being? If they do, I don't understand why. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
On Tue, Dec 29, 2009 at 22:54, Martijn Faassen <faassen@startifact.com> wrote:
Because we have a ton of installed base out there
Do we? I think the debate is somewhat confused here, or possibly it's only me. :)
I agree that the debate is confused. No one intends to declare that zope.app is dead. However, dropping zope.app from ZTK is a declaration that newcomers to ZTK will not have to learn anything in zope.app in order to become productive, which is a big win IMHO. Shane
Hanno Schlichting wrote:
zope.file
I think this package is just misnamed and should have been zope.app.file. It's a full blown content type implementation, with dependencies on zope.app.form, providing browser view code, browser menus and quite a bit of zope.app integration. It's test setup needs a full blown ZODB and publisher environment.
ACTION: I'd remove this from the ZTK until someone is willing to refactor it to provide a minimal file implementation.
+1
zope.formlib and friends
zope.formlib depends on zope.app.form which in turn depends on many zope.app packages. zope.html and zope.mimetype both depend on zope.formlib or zope.app.form.
Various people myself included looked at the zope.formlib / zope.app.form split to see if it can be refactored in a sensible way. I think the conclusion has so far been: there's just no way. There isn't a sensible set of basic principles or interfaces in formlib, that can form a base for a higher level zope.app.form. All the packages using formlib today actually make use of the widgets in zope.app.form and thus basically on the entire functionality.
I'm probably not seeing something, but wouldn't we be able to just move the widgets from zope.app.form into zope.formlib? The non-test dependencies of zope.app.form don't look that bad.
zope.testbrowser
This package offers functional browser tests and consequently needs a way to set up a ZODB and publisher with some default application configuration. I don't see how this can be achieved without depending on a specific application environment like zope.app.appsetup or Zope2/App. Zope2 depends on the package and it makes sense to include it on the application server level - but not on a toolkit level for building frameworks.
ACTION: I'd suggest to drop this package from the ZTK.
If there are multiple frameworks that use this (and there are, Zope 2, Grok, Zope 3 apps), shouldn't just drop it. We could move it into the 'under review' status or something. Regards, Martijn
On Mon, Dec 28, 2009 at 11:05:29PM +0100, Martijn Faassen wrote:
Hanno Schlichting wrote:
zope.testbrowser
This package offers functional browser tests and consequently needs a way to set up a ZODB and publisher with some default application configuration. I don't see how this can be achieved without depending on a specific application environment like zope.app.appsetup or Zope2/App. Zope2 depends on the package and it makes sense to include it on the application server level - but not on a toolkit level for building frameworks.
ACTION: I'd suggest to drop this package from the ZTK.
If there are multiple frameworks that use this (and there are, Zope 2, Grok, Zope 3 apps), shouldn't just drop it. We could move it into the 'under review' status or something.
Refactoring bits so that you could use zope.testbrowser for writing functional tests without depending on zope.app.testing's functional test bits would be nice. Maybe split off the zope.app-depending bits into zope.app.testbrowser? Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
participants (7)
-
Hanno Schlichting -
Lennart Regebro -
Marius Gedminas -
Martijn Faassen -
Shane Hathaway -
Tres Seaver -
Wichert Akkerman