Proposal: Merge philikon-aq branch into Zope trunk
Hi. I'd like to propose to merge the philikon-aq branch into Zope trunk aka Zope 2.12. Scope: For those unfamiliar with the branch, it makes Acquisition aware of __parent__ pointers. This makes it unnecessary to use Acquisition mixin's for Zope 3 code to use them in Zope 2 code. The security machinery of Zope 2 will still be able to work as expected. Status: All tests in the Zope itself pass. New tests have been written for all edge cases found during the development of the branch. As a real world exposure Plone has been used to test the branch. All tests in Plone except one edge-case of a monkey-patch loaded package still pass. Plone in current versions make heavy use of Zope 3 and Five technologies inside Zope 2, so I see this as a very good indicator for the readiness of the branch. The one edge-case is something which needs to be fixed in Plone, as it doesn't make use of any official API. Risks: Using Zope 3 code inside Zope 2 has lead to various 'inventive solutions' to work around problems. Some of these have not used official API's. It is possible that some of those might need to be adjusted. Adjusting them should be straight forward in most cases and mostly consist of removing the hackish workarounds. The second problem that might arise, is that the implicit assumption that every object inside Zope 2 inherits from Acquisition base classes no longer holds. Code that relies on the various aq_* attributes to be there need to be adjusted to use the Acquisition methods instead. This change is trivial to do and doesn't need to be done at first. It only needs to be done when you want to allow direct Zope 3 code in your application. As part of the branch all code in Zope 2 itself have been adjusted to use the aq_* methods. Timeline: I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems. Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test. Opinions, votes? Hanno P.S. Thanks to philiKON for doing most of the work on this branch :)
On Thu, Apr 17, 2008 at 12:27 PM, Hanno Schlichting <plone@hannosch.info> wrote:
I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems.
Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test.
Opinions, votes?
+sys.maxint! Thanks, Hanno, for carrying this to it's completion! -- Martijn Pieters
On Thu, Apr 17, 2008 at 12:43:25PM +0200, Martijn Pieters wrote:
On Thu, Apr 17, 2008 at 12:27 PM, Hanno Schlichting <plone@hannosch.info> wrote:
I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems.
Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test.
Opinions, votes?
+sys.maxint!
Darn. My +1 won't fit in there anymore! -- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
Christian Theune wrote:
On Thu, Apr 17, 2008 at 12:43:25PM +0200, Martijn Pieters wrote:
On Thu, Apr 17, 2008 at 12:27 PM, Hanno Schlichting <plone@hannosch.info> wrote:
I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems.
Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test.
Opinions, votes? +sys.maxint!
Darn. My +1 won't fit in there anymore!
perhaps martijn's still on 32-bit? :) anyway, +1 from me as well. andi -- zeidler it consulting - http://zitc.de/ - info@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.1rc1 released! -- http://plone.org/products/plone/
Previously Martijn Pieters wrote:
On Thu, Apr 17, 2008 at 12:27 PM, Hanno Schlichting <plone@hannosch.info> wrote:
I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems.
Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test.
Opinions, votes?
+sys.maxint!
I'm afraid any further +1s will turn that into a negative score now. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Hanno Schlichting wrote:
Timeline:
I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems.
Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test.
This sounds good. Here's another idea, though: In accordance with "release early and often", how about scheduling the 2.12 release shortly after the 2.11 one? So the only "new" thing in 2.12 would be the philikon-aq branch (it would still ship with the same Zope 3 libraries as 2.11, etc.).
Opinions, votes?
+1 :)
P.S. Thanks to philiKON for doing most of the work on this branch :)
And thanks to Hanno for testing it against Plone and making lots of improvements!
Previously Philipp von Weitershausen wrote:
This sounds good. Here's another idea, though: In accordance with "release early and often", how about scheduling the 2.12 release shortly after the 2.11 one? So the only "new" thing in 2.12 would be the philikon-aq branch (it would still ship with the same Zope 3 libraries as 2.11, etc.).
+1 Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test.
This sounds good. Here's another idea, though: In accordance with "release early and often", how about scheduling the 2.12 release shortly after the 2.11 one? So the only "new" thing in 2.12 would be the philikon-aq branch (it would still ship with the same Zope 3 libraries as 2.11, etc.).
I suspect we want to do something about the eggification story of Zope 2 for Zope 2.12 as well. Figuring out the approach and documenting it might take some additional time. I don't see that releasing another Zope 2.13 shortly after 2.12 makes a lot of sense. Hanno
Hanno Schlichting wrote:
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test. This sounds good. Here's another idea, though: In accordance with "release early and often", how about scheduling the 2.12 release shortly after the 2.11 one? So the only "new" thing in 2.12 would be the philikon-aq branch (it would still ship with the same Zope 3 libraries as 2.11, etc.).
I suspect we want to do something about the eggification story of Zope 2 for Zope 2.12 as well. Figuring out the approach and documenting it might take some additional time. I don't see that releasing another Zope 2.13 shortly after 2.12 makes a lot of sense.
Why don't we get started on that, too, then? I think eggification of Zope 2 is relatively easy, and most of the necessary R&D has already been done. In fact, a lot of the eggs exist already. I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
Hanno Schlichting wrote:
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test. This sounds good. Here's another idea, though: In accordance with "release early and often", how about scheduling the 2.12 release shortly after the 2.11 one? So the only "new" thing in 2.12 would be the philikon-aq branch (it would still ship with the same Zope 3 libraries as 2.11, etc.).
I suspect we want to do something about the eggification story of Zope 2 for Zope 2.12 as well. Figuring out the approach and documenting it might take some additional time. I don't see that releasing another Zope 2.13 shortly after 2.12 makes a lot of sense.
Why don't we get started on that, too, then?
I think eggification of Zope 2 is relatively easy, and most of the necessary R&D has already been done. In fact, a lot of the eggs exist already.
I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input.
IMO, a Zope2 egg release should depend on the following packages: - 'ZODB3' (already packaged) - 'transaction' (depended on by newer ZODBs) - 'ZConfig' (also depended on by newer ZODBs) - 'StructuredText' (should be broken out into its own egg) - 'docutils' (should use existing egg) - 'mechanize' (should use existing egg) - 'pytz' (should use existing egg) - all zope.* packages (properly pinned) that zope2 depends on The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc). We might call it 'zope2libs'. What needs to get worked out is the ability to share headers between ZODB and this package so things can compile properly. - C
Chris McDonough wrote:
I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input.
IMO, a Zope2 egg release should depend on the following packages:
- 'ZODB3' (already packaged)
- 'transaction' (depended on by newer ZODBs)
- 'ZConfig' (also depended on by newer ZODBs)
- 'StructuredText' (should be broken out into its own egg)
- 'docutils' (should use existing egg)
- 'mechanize' (should use existing egg)
- 'pytz' (should use existing egg)
- all zope.* packages (properly pinned) that zope2 depends on
Yup. These are all done already.
The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc).
Yup, we can do it like that. I still maintain that the zLOG, Interface and DateTime packages could be packaged separately without much effort. The benefit with those is that they'll either be obsolete very soon (zLOG, Interface) or may need off-beat updates (DateTime).
We might call it 'zope2libs'.
What's wrong with just 'Zope2'?
What needs to get worked out is the ability to share headers between ZODB and this package so things can compile properly.
I don't see this as a huge problem. You have a point that C headers introduce un-documented dependencies, but then again, how often do C headers change? It has worked so far with externals to the ZODB tree, it's not like anything's going to change there any time soon. (For instance, when I hacked Acquisition to support __parent__ pointers, I didn't have to change the headers either).
Philipp von Weitershausen wrote:
Chris McDonough wrote:
I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input.
IMO, a Zope2 egg release should depend on the following packages:
- 'ZODB3' (already packaged)
- 'transaction' (depended on by newer ZODBs)
- 'ZConfig' (also depended on by newer ZODBs)
- 'StructuredText' (should be broken out into its own egg)
- 'docutils' (should use existing egg)
- 'mechanize' (should use existing egg)
- 'pytz' (should use existing egg)
- all zope.* packages (properly pinned) that zope2 depends on
Yup. These are all done already.
The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc).
Yup, we can do it like that. I still maintain that the zLOG, Interface and DateTime packages could be packaged separately without much effort. The benefit with those is that they'll either be obsolete very soon (zLOG, Interface) or may need off-beat updates (DateTime).
I'd be slightly happier if everything "we" (Zope 2 folks, as opposed to Zope 3 folks, ZODB folks, or other independent authors) maintain shipped inside a single egg. In particular, I think this might be what to aim for in the very first Zope 2 egg-based release, because we can always move stuff out in a later release, but it's harder to reel something back in if we find that moving it out has been a mistake. The "one big egg" strategy might also let us explain it a little more easier to old-hand Zope2 devs who aren't used to eggs: "everything that used to be in the tarball except ZODB, Zope 3 libraries, and external libs is in the zope2 egg". Then in a subsequent Zope 2 egg release, we could say "oh, now that you're used to eggs, we've moved DateTime out into a separate egg", so on and so forth. But I'll try not to get hung up on it if other really want to bust things apart. I guess in particular, I'm not keen on trying to externalize ExtensionClass or Acquisition unless somebody else has a strong desire to do this because they're using them outside Zope somehow.
We might call it 'zope2libs'.
What's wrong with just 'Zope2'?
It would be nice to disambiguate the libraries needed to run Zope 2 from the wrapper stuff required to configure an instance. The very outmost "meta-egg" (or buildout, or whatever) should probably be named Zope2. This might or might not be it. If this *is* that outermost egg, "Zope2" sounds good to me. A nit: I might call the outermost egg "zope2" because I have a preference for lowercase egg names and we also already have a *package* named "Zope2", and it'd be nice to know where you are at the bash prompt without needing to print the whole path.
What needs to get worked out is the ability to share headers between ZODB and this package so things can compile properly.
I don't see this as a huge problem. You have a point that C headers introduce un-documented dependencies, but then again, how often do C headers change? It has worked so far with externals to the ZODB tree, it's not like anything's going to change there any time soon. (For instance, when I hacked Acquisition to support __parent__ pointers, I didn't have to change the headers either).
We can probably manage it by being careful to match up egg dependencies to externals at release time. If folks force an install that doesn't make sense dependency-wise, they can lose. - C
On 19 Apr 2008, at 22:39 , Chris McDonough wrote:
Philipp von Weitershausen wrote:
Chris McDonough wrote:
I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input.
IMO, a Zope2 egg release should depend on the following packages:
- 'ZODB3' (already packaged)
- 'transaction' (depended on by newer ZODBs)
- 'ZConfig' (also depended on by newer ZODBs)
- 'StructuredText' (should be broken out into its own egg)
- 'docutils' (should use existing egg)
- 'mechanize' (should use existing egg)
- 'pytz' (should use existing egg)
- all zope.* packages (properly pinned) that zope2 depends on Yup. These are all done already. The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc). Yup, we can do it like that. I still maintain that the zLOG, Interface and DateTime packages could be packaged separately without much effort. The benefit with those is that they'll either be obsolete very soon (zLOG, Interface) or may need off-beat updates (DateTime).
I'd be slightly happier if everything "we" (Zope 2 folks, as opposed to Zope 3 folks, ZODB folks, or other independent authors) maintain shipped inside a single egg.
In particular, I think this might be what to aim for in the very first Zope 2 egg-based release, because we can always move stuff out in a later release, but it's harder to reel something back in if we find that moving it out has been a mistake. The "one big egg" strategy might also let us explain it a little more easier to old- hand Zope2 devs who aren't used to eggs: "everything that used to be in the tarball except ZODB, Zope 3 libraries, and external libs is in the zope2 egg". Then in a subsequent Zope 2 egg release, we could say "oh, now that you're used to eggs, we've moved DateTime out into a separate egg", so on and so forth.
Ok, fine by me.
But I'll try not to get hung up on it if other really want to bust things apart. I guess in particular, I'm not keen on trying to externalize ExtensionClass or Acquisition unless somebody else has a strong desire to do this because they're using them outside Zope somehow.
Which they're not :).
We might call it 'zope2libs'. What's wrong with just 'Zope2'?
It would be nice to disambiguate the libraries needed to run Zope 2 from the wrapper stuff required to configure an instance. The very outmost "meta-egg" (or buildout, or whatever) should probably be named Zope2. This might or might not be it. If this *is* that outermost egg, "Zope2" sounds good to me.
Well, taking your "everything that used to be in the tarball..." argument, then this would indeed be the outmost egg, incl. the instance scripts.
A nit: I might call the outermost egg "zope2" because I have a preference for lowercase egg names and we also already have a *package* named "Zope2", and it'd be nice to know where you are at the bash prompt without needing to print the whole path.
I have a slight preference for "Zope2" because that's what egg names usually look like. Also, if you told people Zope 2 was now available in egg form and asked them to guess what the egg was called, I think most would come up with "Zope2".
Philipp von Weitershausen wrote:
I'd be slightly happier if everything "we" (Zope 2 folks, as opposed to Zope 3 folks, ZODB folks, or other independent authors) maintain shipped inside a single egg.
In particular, I think this might be what to aim for in the very first Zope 2 egg-based release, because we can always move stuff out in a later release, but it's harder to reel something back in if we find that moving it out has been a mistake. The "one big egg" strategy might also let us explain it a little more easier to old-hand Zope2 devs who aren't used to eggs: "everything that used to be in the tarball except ZODB, Zope 3 libraries, and external libs is in the zope2 egg". Then in a subsequent Zope 2 egg release, we could say "oh, now that you're used to eggs, we've moved DateTime out into a separate egg", so on and so forth.
Ok, fine by me.
Cool.
But I'll try not to get hung up on it if other really want to bust things apart. I guess in particular, I'm not keen on trying to externalize ExtensionClass or Acquisition unless somebody else has a strong desire to do this because they're using them outside Zope somehow.
Which they're not :).
We might call it 'zope2libs'. What's wrong with just 'Zope2'?
It would be nice to disambiguate the libraries needed to run Zope 2 from the wrapper stuff required to configure an instance. The very outmost "meta-egg" (or buildout, or whatever) should probably be named Zope2. This might or might not be it. If this *is* that outermost egg, "Zope2" sounds good to me.
Well, taking your "everything that used to be in the tarball..." argument, then this would indeed be the outmost egg, incl. the instance scripts.
True, although the Zope2 instance-creation scripts will probably become setuptools console scripts, which means that things will likely need to get shuffled around a bit from how things are now regardless and old hands will be baffled anyway. repoze.zope2 needs the libraries, but doesn't need the stock Zope instance creation scripts (repoze.zope2's may actually conflict name-wise with those from "stock" Zope 2). I'll see if I can figure out a way that repoze.zope2 can just use stock zope2 instance-creation scripts so making a different meta-egg that includes just instance creation stuff isn't as attractive.
A nit: I might call the outermost egg "zope2" because I have a preference for lowercase egg names and we also already have a *package* named "Zope2", and it'd be nice to know where you are at the bash prompt without needing to print the whole path.
I have a slight preference for "Zope2" because that's what egg names usually look like. Also, if you told people Zope 2 was now available in egg form and asked them to guess what the egg was called, I think most would come up with "Zope2".
Alright. I'm excited about this. ;-) - C
Hi. Chris McDonough wrote:
True, although the Zope2 instance-creation scripts will probably become setuptools console scripts, which means that things will likely need to get shuffled around a bit from how things are now regardless and old hands will be baffled anyway.
repoze.zope2 needs the libraries, but doesn't need the stock Zope instance creation scripts (repoze.zope2's may actually conflict name-wise with those from "stock" Zope 2). I'll see if I can figure out a way that repoze.zope2 can just use stock zope2 instance-creation scripts so making a different meta-egg that includes just instance creation stuff isn't as attractive.
We have lots of instance creation logic in the plone.recipe.zope2instance package as well. While it currently still calls mkzope2instance internally, there isn't really anything from it which it depends on anymore. While this code is currently zc.buildout specific, I would favor a smarter general instance creation script where we could offload all logic to. Currently there is too much zope.conf building stuff and a improved test runner and control script in that recipe, where lots of the parts are reusable. Most of this is providing a Python API to build zope.conf and adjusting the default values of some options to more sensible values. We also have the zope2zeoserver recipe which on top provides the missing Windows support scripts and adjustments for ZEO. Do people feel any of this should be more generally reusable? What does repoze.zope2 currently do in this area or would like to do? Hanno
Hanno Schlichting wrote:
Hi.
Chris McDonough wrote:
True, although the Zope2 instance-creation scripts will probably become setuptools console scripts, which means that things will likely need to get shuffled around a bit from how things are now regardless and old hands will be baffled anyway.
repoze.zope2 needs the libraries, but doesn't need the stock Zope instance creation scripts (repoze.zope2's may actually conflict name-wise with those from "stock" Zope 2). I'll see if I can figure out a way that repoze.zope2 can just use stock zope2 instance-creation scripts so making a different meta-egg that includes just instance creation stuff isn't as attractive.
We have lots of instance creation logic in the plone.recipe.zope2instance package as well. While it currently still calls mkzope2instance internally, there isn't really anything from it which it depends on anymore.
While this code is currently zc.buildout specific, I would favor a smarter general instance creation script where we could offload all logic to. Currently there is too much zope.conf building stuff and a improved test runner and control script in that recipe, where lots of the parts are reusable. Most of this is providing a Python API to build zope.conf and adjusting the default values of some options to more sensible values. We also have the zope2zeoserver recipe which on top provides the missing Windows support scripts and adjustments for ZEO.
Do people feel any of this should be more generally reusable? What does repoze.zope2 currently do in this area or would like to do?
repoze.zope2 doesn't use any of the instance-file-creation stuff in Zope. So far we haven't much want to either, because creating instances is pretty easy. Also, because repoze.zope2 depends on PasteScript, we have the opportunity to use "paster create" to create repoze.zope2 instances. Although we don't yet do that, that might be the natural way for us to go if we did want to use any framework to create instances. But "paster create" would probably not be a reasonable way to generate instances for "plain old Zope", because it would form a dependency on PasteScript, which Zope 2 doesn't currently need otherwise. But with that in mind, I think we would be happiest if there was an egg that could be installed that got all the Zope libs but which didn't subsequently install instance creation / instance management console scripts (back to the "zope2libs" idea..). Might that also be the case for Plone? - C
Hey, Hanno, this is a major step forward! +1 from me as well. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Hi.
I'd like to propose to merge the philikon-aq branch into Zope trunk aka Zope 2.12.
Scope:
For those unfamiliar with the branch, it makes Acquisition aware of __parent__ pointers. This makes it unnecessary to use Acquisition mixin's for Zope 3 code to use them in Zope 2 code. The security machinery of Zope 2 will still be able to work as expected.
Status:
All tests in the Zope itself pass. New tests have been written for all edge cases found during the development of the branch.
As a real world exposure Plone has been used to test the branch. All tests in Plone except one edge-case of a monkey-patch loaded package still pass. Plone in current versions make heavy use of Zope 3 and Five technologies inside Zope 2, so I see this as a very good indicator for the readiness of the branch. The one edge-case is something which needs to be fixed in Plone, as it doesn't make use of any official API.
Risks:
Using Zope 3 code inside Zope 2 has lead to various 'inventive solutions' to work around problems. Some of these have not used official API's. It is possible that some of those might need to be adjusted. Adjusting them should be straight forward in most cases and mostly consist of removing the hackish workarounds.
The second problem that might arise, is that the implicit assumption that every object inside Zope 2 inherits from Acquisition base classes no longer holds. Code that relies on the various aq_* attributes to be there need to be adjusted to use the Acquisition methods instead.
The major downside here is that restricted code doesn't have access to the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and hence use the attributes. ('aq_base' should not be allowewd at all, as it strips away security context). There are probably thousands (or even tens of thousands) of templates and scripts "in the wild" which use these attributes. I don't think we can break them in a single release: we need to deprecate them first (with suitalbe logging output), and maybe even provide '__parent__'-aware workarounds / fallbacks in their implementations.
This change is trivial to do and doesn't need to be done at first. It only needs to be done when you want to allow direct Zope 3 code in your application. As part of the branch all code in Zope 2 itself have been adjusted to use the aq_* methods.
Good!
Timeline:
I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems.
Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test.
Opinions, votes?
Hanno
P.S. Thanks to philiKON for doing most of the work on this branch :)
Many kudos to both of you. 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 iD8DBQFIB4NT+gerLs4ltQ4RAvFlAKDLXkUC/ffrP4pGfNFC94Q815GcQgCfXqFU WqXqkO8p6JAZiOT4zpgg4wQ= =iWAn -----END PGP SIGNATURE-----
Tres Seaver wrote:
The second problem that might arise, is that the implicit assumption that every object inside Zope 2 inherits from Acquisition base classes no longer holds. Code that relies on the various aq_* attributes to be there need to be adjusted to use the Acquisition methods instead.
The major downside here is that restricted code doesn't have access to the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and hence use the attributes. ('aq_base' should not be allowewd at all, as it strips away security context).
There are probably thousands (or even tens of thousands) of templates and scripts "in the wild" which use these attributes. I don't think we can break them in a single release: we need to deprecate them first (with suitalbe logging output), and maybe even provide '__parent__'-aware workarounds / fallbacks in their implementations.
Here's the deal: * Instances of (subclasses of) Acquisition.Implicit and .Explicit still have those aq_* attributes. So basically all content objects still have them, no change there. * Five's BrowserView class doesn't inherit from Acquisition.Explicit anymore, but we've provided the aq_* attributes for backward compatibility. So if a template does view/aq_parent, it will still work (we have tests for this). We haven't set an expiry date for this BBB, nor are we logging a warning. We probably should, though, if we eventually want to phase out Five's BrowserView class. So, off the line there's no backward-compatibility problem. Now if people decide to implement their content objects without Acquisition (which they now can), then it's their problem if their templates still do obj/aq_*. This can be alleviated with a mix-in that Five has, which makes classes regain the aq_* attributes. Not sure if we want to make this public in any way, currently it's basically used for BrowserView and ViewletBase.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
Tres Seaver wrote:
The second problem that might arise, is that the implicit assumption that every object inside Zope 2 inherits from Acquisition base classes no longer holds. Code that relies on the various aq_* attributes to be there need to be adjusted to use the Acquisition methods instead. The major downside here is that restricted code doesn't have access to the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and hence use the attributes. ('aq_base' should not be allowewd at all, as it strips away security context).
There are probably thousands (or even tens of thousands) of templates and scripts "in the wild" which use these attributes. I don't think we can break them in a single release: we need to deprecate them first (with suitalbe logging output), and maybe even provide '__parent__'-aware workarounds / fallbacks in their implementations.
Here's the deal:
* Instances of (subclasses of) Acquisition.Implicit and .Explicit still have those aq_* attributes. So basically all content objects still have them, no change there.
* Five's BrowserView class doesn't inherit from Acquisition.Explicit anymore, but we've provided the aq_* attributes for backward compatibility. So if a template does view/aq_parent, it will still work (we have tests for this). We haven't set an expiry date for this BBB, nor are we logging a warning. We probably should, though, if we eventually want to phase out Five's BrowserView class.
So, off the line there's no backward-compatibility problem. Now if people decide to implement their content objects without Acquisition (which they now can), then it's their problem if their templates still do obj/aq_*. This can be alleviated with a mix-in that Five has, which makes classes regain the aq_* attributes. Not sure if we want to make this public in any way, currently it's basically used for BrowserView and ViewletBase.
I realized after I sent it that BBB was "automatic" for the content objects, making only views a possible issue: I'm glad to learn that the views have the attributes available. I would recommend a "perpetual deprecation" for the view BBB (log the warning with a note of the recommended change, but don't indicate a removal release). In any case, given the clarification, +1 to the merge. 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 iD8DBQFICKz6+gerLs4ltQ4RAqI9AJ9wWjhsca8iljbeb8z77eHMHgBv/gCdHfa4 SkkZqvDRAxPLPicSQM8ZCPQ= =o+xz -----END PGP SIGNATURE-----
Tres Seaver wrote: [snip]
The second problem that might arise, is that the implicit assumption that every object inside Zope 2 inherits from Acquisition base classes no longer holds. Code that relies on the various aq_* attributes to be there need to be adjusted to use the Acquisition methods instead.
The major downside here is that restricted code doesn't have access to the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and hence use the attributes. ('aq_base' should not be allowewd at all, as it strips away security context).
There are probably thousands (or even tens of thousands) of templates and scripts "in the wild" which use these attributes. I don't think we can break them in a single release: we need to deprecate them first (with suitalbe logging output), and maybe even provide '__parent__'-aware workarounds / fallbacks in their implementations.
I'm trying to understand what is proposed that would break them. All existing content objects will continue to use acquisition. Only things like Five views will stop using acquisition and switch to a __parent__ pointer. I doubt there are that many scripts that rely on getting a .aq_parent, say, on a Five view. There will be view code that relies on this, so I imagine we expect that should be rewritten to use the functions instead, but not scripts. If we were to change OFS so that it'd start using __parent__ then I can see where you're coming from, but I don't think anyone's proposing that? Regards, Martijn
Martijn Faassen wrote:
Tres Seaver wrote: [snip]
The second problem that might arise, is that the implicit assumption that every object inside Zope 2 inherits from Acquisition base classes no longer holds. Code that relies on the various aq_* attributes to be there need to be adjusted to use the Acquisition methods instead.
The major downside here is that restricted code doesn't have access to the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and hence use the attributes. ('aq_base' should not be allowewd at all, as it strips away security context).
There are probably thousands (or even tens of thousands) of templates and scripts "in the wild" which use these attributes. I don't think we can break them in a single release: we need to deprecate them first (with suitalbe logging output), and maybe even provide '__parent__'-aware workarounds / fallbacks in their implementations.
I'm trying to understand what is proposed that would break them. All existing content objects will continue to use acquisition. Only things like Five views will stop using acquisition and switch to a __parent__ pointer. I doubt there are that many scripts that rely on getting a .aq_parent, say, on a Five view. There will be view code that relies on this, so I imagine we expect that should be rewritten to use the functions instead, but not scripts.
You're right, and Tres acknowledged that in a follow-up post already :). What's more, views actually *do* have those aq_* attributes for BBB, so even those scripts that do view.aq_parent will continue to work no problem. See my answer to Tres's post.
If we were to change OFS so that it'd start using __parent__ then I can see where you're coming from, but I don't think anyone's proposing that?
Nope. And it would be quite an involved thing to do, because currently Zope 2 objects have no persistent reference to their parent whatsoever (in fact, parent i.e. cyclic references used to be unsupported by early ZODB versions). So basically, if you wanted to introduce __parent__ pointers to existing Zope 2 objects, you'd have to traverse the whole object tree and set them based on their acquisition parent. I *suppose* this could be done ad-hoc (when you first traverse over an object that doesn't yet have its __parent__ pointer set), but I'd rather not think this through right now. So, like I said, it's not on my list, and I bet it won't be for a long time. Mostly because a) it's probably unnecessary and b) much code in fact relies on content being of the type Acquisition.Implicit... <dtml-var standard_dtml_header> anyone? :)
Hi. Hanno Schlichting wrote:
I'd like to propose to merge the philikon-aq branch into Zope trunk aka Zope 2.12.
[...]
Timeline:
I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems.
Just as a note for those interested: I'm working on this now, but ran into some merge problems which took more time to figure out than I had this weekend. I'll continue ASAP. Stay tuned ;) Hanno
Hanno Schlichting wrote:
Hanno Schlichting wrote:
I'd like to propose to merge the philikon-aq branch into Zope trunk aka Zope 2.12.
[...]
Timeline:
I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems.
This branch is merged now. Death to Acquisition, long live Zope! Hanno
participants (13)
-
Andreas Jung -
Andreas Zeidler -
Chris McDonough -
Christian Theune -
Hanno Schlichting -
Jens Vagelpohl -
Martijn Faassen -
Martijn Pieters -
Martin Aspeli -
Philipp von Weitershausen -
Stefan H. Holek -
Tres Seaver -
Wichert Akkerman