A Modest Proposal Concerning Monkey Patches
There is a large problem looming with Moneky Patches. The problem is that monkey patches are so Highlander. "There can be Only One". For example, there are at least five or six products that monkey patch manage_main. Each simply replaces whatever manage_main exists at the time of instantation, and blows away any previous monkey patch. Some coordinated way of dealing with this problem needs to be arrived at. Proposal: for concreteness sake, suppose manage_main is being patched. A monkey patch author does the following: 1) checks to see if the file being patched is in $(INSTANCE_HOME)/tmp A) If not, he proceeds directly with the patch B) If so, he makes whatever checks he can to determine if he can update the file in $(INSTANCE_HOME)/tmp. i) If he cannot, it is his decision whether to follow current practice and simply blow away the current monkey patch (Boo! Hiss!) or, ii) fail (sigh, curse!). 2) If the monkey patch is installed, then the installed file is written in $(INSTANCE_HOME)/tmp. I.e., the new manage_main.py is written to $(INSTANCE_HOME)/tmp. This assumes that z2.py is modified so that it clears out $(INSTANCE_HOME)/tmp on each start. It might be also be a good idea to keep a section of comments at the top of the monkeypatch file showing the history of monkeypatch application. Comments? Jim Penny
On Tue, 13 Aug 2002, Jim Penny wrote:
B) If so, he makes whatever checks he can to determine if he can update the file in $(INSTANCE_HOME)/tmp.
Updating a (disk based) file and monkey patching don't seem to go together in my mind. I'm really unclear what you are proposing here.
2) If the monkey patch is installed, then the installed file is written in $(INSTANCE_HOME)/tmp. I.e., the new manage_main.py is written to $(INSTANCE_HOME)/tmp.
Again, monkey patching doesn't modify source code, so I don't know what would be getting written into tmp.
Comments?
Didn't someone else make a proposal (with code) to handle this? Was it PatchKit? But yes, some "standard" would be helpful, possibly with supporting utilities, to allow multiple monkeypatches coexist, I think. On the other hand, in Zope3 you just change the zcml files...although I think there was a discusion of an analogous issue there (coexistence of multiple "modifications" to the same area) and I'm not sure a conclusion was reached (but I can't remember for sure). --RDM
Again, monkey patching doesn't modify source code, so I don't know what would be getting written into tmp.
Comments?
Didn't someone else make a proposal (with code) to handle this? Was it PatchKit?
Yup, and it is more than a proposal, it is a full blown product ( http://www.zope.org/Members/haqa/PatchKit ) with some patches already in it (They can be removed if you wish). There is a fledgling API, though I probably need to document it better, make some unit tests etc, but it is there, and it works (For me... YMMV).
But yes, some "standard" would be helpful, possibly with supporting utilities, to allow multiple monkeypatches coexist, I think.
On the other hand, in Zope3 you just change the zcml files...although I think there was a discusion of an analogous issue there (coexistence of multiple "modifications" to the same area) and I'm not sure a conclusion was reached (but I can't remember for sure).
Adrian... -- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk
On Wed, Aug 14, 2002 at 08:46:41AM +0100, Adrian Hungate wrote:
Again, monkey patching doesn't modify source code, so I don't know what would be getting written into tmp.
Comments?
Didn't someone else make a proposal (with code) to handle this? Was it PatchKit?
Yup, and it is more than a proposal, it is a full blown product ( http://www.zope.org/Members/haqa/PatchKit ) with some patches already in it (They can be removed if you wish).
Nope... we have been down this path before. Note this what I need (see below on why) requires modification, and not simple replacement, of whatever code is currently running. As far as I can see, Patchkit does nothing to make this possible. The problem is that A) monkey patches may or may not have been applied before a given product sees anything, and B) there is no reasonable way to discover what (or even if) patches have been applied by other products. If you are going to go down the monkeypatch path, then there needs to be some way for other monkeypatchers to discover what you have done, so that they can decide if they can 1) extend your code to be compatible with theirs, 2) refuse to install their code, or 3) blow your pre-existing code away. Current monkeypatch code always does 3. Patchkit has, as far as I can tell no way to make 1 or 2 easier. It just makes it easier to blow other people's work away! Background: I am debian maintainer for zope-zshell. The debian release is currently a version behind. I have been holding off updating it because I would like the ZMI box. I cannot modify manage_main.py directly, because it belongs to the zope package and the changes would be blown away on any upgrade of zope. I was starting to turn it into a python product, but zope-externaleditor has been packaged, and it monkeypatches manage_main. The naive thing to do would be to install it as a monkeypatch. But then, either I blow away externaleditor, or externaleditor blows away zshell, depending on the order in which zope installs products on startup. There are several other products that monkeypatch manage_main as well, building a nice mutual destruction club. Jim Penny PS: I would also like to hear general responses to Jerome's proposal. Clearly this was not an API, no arguments have been specified. But is there a general consensus that this is a reasonable thing to do? Please, if it isn't to late, could we make it a 2.6 thing?
There is a fledgling API, though I probably need to document it better, make some unit tests etc, but it is there, and it works (For me... YMMV).
But yes, some "standard" would be helpful, possibly with supporting utilities, to allow multiple monkeypatches coexist, I think.
On the other hand, in Zope3 you just change the zcml files...although I think there was a discusion of an analogous issue there (coexistence of multiple "modifications" to the same area) and I'm not sure a conclusion was reached (but I can't remember for sure).
Adrian...
-- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk
Hmm... ok, now I see what you are talking about, however, you are talking about modifying a DTMLFile object - I am not sure of any reliable API (Or even magic) that will allow that to happen in a "play nice with others" way. Just for clarity's sake (For me if no-one else), what object type are you wanting to change manage_main for? I have to admit to not knowing zshell or external_editor well, but I have seen mentions of ee making changes to the ZMI - I had assumed this was the addition of tabs (And DTMLFiles), not the replacement of them. I take it I was wrong in this assumption? Adrian... -- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk ----- Original Message ----- From: "Jim Penny" <jpenny@universal-fasteners.com> To: "Adrian Hungate" <adrian@haqa.co.uk>; <zope-dev@zope.org> Sent: Wednesday, August 14, 2002 3:34 PM Subject: Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches
On Wed, Aug 14, 2002 at 08:46:41AM +0100, Adrian Hungate wrote:
Again, monkey patching doesn't modify source code, so I don't know what would be getting written into tmp.
Comments?
Didn't someone else make a proposal (with code) to handle this? Was it PatchKit?
Yup, and it is more than a proposal, it is a full blown product ( http://www.zope.org/Members/haqa/PatchKit ) with some patches already in it (They can be removed if you wish).
Nope... we have been down this path before. Note this what I need (see below on why) requires modification, and not simple replacement, of whatever code is currently running. As far as I can see, Patchkit does nothing to make this possible.
The problem is that A) monkey patches may or may not have been applied before a given product sees anything, and B) there is no reasonable way to discover what (or even if) patches have been applied by other products.
If you are going to go down the monkeypatch path, then there needs to be some way for other monkeypatchers to discover what you have done, so that they can decide if they can 1) extend your code to be compatible with theirs, 2) refuse to install their code, or 3) blow your pre-existing code away.
Current monkeypatch code always does 3. Patchkit has, as far as I can tell no way to make 1 or 2 easier. It just makes it easier to blow other people's work away!
Background: I am debian maintainer for zope-zshell. The debian release is currently a version behind. I have been holding off updating it because I would like the ZMI box. I cannot modify manage_main.py directly, because it belongs to the zope package and the changes would be blown away on any upgrade of zope. I was starting to turn it into a python product, but zope-externaleditor has been packaged, and it monkeypatches manage_main. The naive thing to do would be to install it as a monkeypatch. But then, either I blow away externaleditor, or externaleditor blows away zshell, depending on the order in which zope installs products on startup. There are several other products that monkeypatch manage_main as well, building a nice mutual destruction club.
Jim Penny
PS: I would also like to hear general responses to Jerome's proposal. Clearly this was not an API, no arguments have been specified. But is there a general consensus that this is a reasonable thing to do? Please, if it isn't to late, could we make it a 2.6 thing?
There is a fledgling API, though I probably need to document it better,
make
some unit tests etc, but it is there, and it works (For me... YMMV).
But yes, some "standard" would be helpful, possibly with supporting utilities, to allow multiple monkeypatches coexist, I think.
On the other hand, in Zope3 you just change the zcml files...although I think there was a discusion of an analogous issue there (coexistence of multiple "modifications" to the same area) and I'm not sure a conclusion was reached (but I can't remember for sure).
Adrian...
-- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk
I know I will regret that I said this, but this is really symptomatic of a more basic need. The need to extend manage_main. This has been identified as a hot spot for products to "monkey" with. Why don't we go right to the source and make manage_main extensible so that monkey patching it isn't necessary? -Casey On Tuesday 13 August 2002 01:22 pm, Jim Penny wrote:
There is a large problem looming with Moneky Patches. The problem is that monkey patches are so Highlander. "There can be Only One".
For example, there are at least five or six products that monkey patch manage_main. Each simply replaces whatever manage_main exists at the time of instantation, and blows away any previous monkey patch. Some coordinated way of dealing with this problem needs to be arrived at.
Proposal:
for concreteness sake, suppose manage_main is being patched.
A monkey patch author does the following:
1) checks to see if the file being patched is in $(INSTANCE_HOME)/tmp
A) If not, he proceeds directly with the patch
B) If so, he makes whatever checks he can to determine if he can update the file in $(INSTANCE_HOME)/tmp.
i) If he cannot, it is his decision whether to follow current practice and simply blow away the current monkey patch (Boo! Hiss!) or,
ii) fail (sigh, curse!).
2) If the monkey patch is installed, then the installed file is written in $(INSTANCE_HOME)/tmp. I.e., the new manage_main.py is written to $(INSTANCE_HOME)/tmp.
This assumes that z2.py is modified so that it clears out $(INSTANCE_HOME)/tmp on each start.
It might be also be a good idea to keep a section of comments at the top of the monkeypatch file showing the history of monkeypatch application.
Comments?
Jim Penny
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Hi, On Tue, Aug 13, 2002 at 01:56:22PM -0400, Casey Duncan wrote:
I know I will regret that I said this, but this is really symptomatic of a more basic need. The need to extend manage_main.
This has been identified as a hot spot for products to "monkey" with. Why don't we go right to the source and make manage_main extensible so that monkey patching it isn't necessary?
What about my proposal of June 6th 2002 in zope-dev ? URL : http://zope.nipltd.com/public/lists/dev-archive.nsf/0a8715d5f3c7b6a3802568c1... I had no answer. bye, Jerome Alet
participants (5)
-
Adrian Hungate -
Casey Duncan -
Jerome Alet -
Jim Penny -
R. David Murray