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  -  [EMAIL PROTECTED]
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 )

Reply via email to