[Zope-dev] A Modest Proposal Concerning Monkey Patches

[Adrian Hungate]

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
> >
> >
>