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 )