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?
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.
> 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
> Jim Penny
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -