[Product-Developers] Removing a removed "required tool" from genericsetup.

ken manheimer ken.manheimer at gmail.com
Tue Sep 6 18:15:35 UTC 2011


On Tue, Sep 6, 2011 at 1:56 PM, Gilles Lenfant
<gilles.lenfant at alterway.fr>wrote:

>
> Le 5 sept. 2011 à 20:34, ken manheimer a écrit :
>
> > On Mon, Sep 5, 2011 at 1:35 PM, Gilles Lenfant <
> gilles.lenfant at alterway.fr> wrote:
> >
> > It seems GenericSetup keeps a footprint of tools that have been once
> installed in a Plone site. Unfortunately, someone before me installed a
> 'foo_tool' I can't find what component's GS profile installed it.
> >
> > Even removing the footprint of that f...g ghost component does not work/
> >
> > del site.portal_setup._toolset_registry._required['foo_too']
> >
> > Is there any clue to get rid of that junk component in the required tools
> ? I can't install anything more in this Plone 3.3 site.
> >
> > Many thanks by advance for any pointer.
> >
> > i think you're touching on a serious issue - one i've certainly struggled
> with, and i'm sure others have, too.  not too long ago (... it was jan 17)
> in included the following posting in my "hints & tips" email folder.  it has
> a kind of recipe for working around the problem, including some steps i've
> had to vaguely rediscover, time and again.  (i would love to have the
> opportunity to do an analysis and see what a proper fix would be, but at
> this point it would take funding.)
> >
> > here's the posting, with full context - hope it's helpful.
> >
> > ken
> >
> > ---------- Forwarded message ----------
> > From: Gil Forcada <gil at usecm.com>
> > Date: Mon, Jan 17, 2011 at 2:25 PM
> > Subject: Re: [Product-Developers] How to cleanly remove a product?
> > To: Dylan Jay <djay at pretaweb.com>
> > Cc: "product-developers at lists.plone.org Developers" <
> product-developers at lists.plone.org>, derek <auspex at pointerstop.ca>, Rok
> Garbas <rok at garbas.si>
> >
> > 2011/1/17 Dylan Jay <djay at pretaweb.com>
> > On 17/01/2011, at 3:06 AM, derek wrote:
> >
> > On Jan 16, 11:16 am, Laurence Rowe <l... at lrowe.co.uk> wrote:
> > hvelarde wrote:
> >
> > guys, is a very bad practice not to write uninstallers (and tests for
> > them) in your products.
> >
> > Unfortunately it is almost impossible to write an uninstaller - as even
> > removing a persistent component registration does not remove all
> references
> > to that key.
> >
> > I'm so thrilled to see that from someone I consider an authoritative
> > source!  "Almost impossible" probably explains why I've yet to find an
> > even half-way decent howto.
> >
> > And for people who write packages as part of customer projects,
> > it is difficult to justify the time to write an uninstaller.
> >
> > Exactly. I'd bite the bullet and try to write a good uninstaller if I
> > was making products for the general public, but for my one-off
> > customer projects it really doesn't seem worth the effort.
> >
> > I think the
> > real solution to this is to make content import/export work work
> correctly
> > (getting close with transmogrifier) so that you can zap and recreate a
> site
> > complete with content.
> >
> > Close, but still no cigar.  Dylan's done a good job with funnelweb, as
> > far as it goes, but there's still a major manual component in
> > importing content.
> >
> > Funnelweb is for "random site"->Plone conversions. There are much better
> tools for Plone->Plone content migrations since they can make more
> assumptions and gain deeper access to the data. Is there a name for these?
> >
> >
> > Ok, FINALLY after a week long looking after this I have them (hopefully)
> gone :)
> >
> > The basic modus operandi was:
> > - add the offending products on the buildout
> > - run the buildout
> > - uninstall all products still installed
> > - force the generic setup code to run by reinstalling a module which has
> propertiestool (membrane for example)
> > - remove all the tools on the ZMI site root
> > - add an ipdb to GenericSetup/registry.py on listRequiredTools method
> (line 576 or so)
> >     [i generally use 'import pdb; pdb.set_trace()', but ipdb looks cool!
> klm]
> > - remove the offending products on the buildout and rerun it
> > - remove the products from ZMI -> Control_Panel -> Products
> > - remove the portal_setup missing steps (if any)
> > - force the generic setup code again and when it hits the ipdb remove the
> tools with a "del self._required['TOOL_NAME']
> >
> > That way they are gone for good!
> >
> > I hope it will be useful to someone.
> >
> > Thanks for all the pointers and ideas!
>
>
> Many thanks for all this.
>
> I have been much more radical than this.
>
> I inserted this in the Products.GenericSetup.tool module in function
> importToolSet around line 123 :
>
>        ...
>        existing = getattr(aq_base(site), tool_id, None)
>        # Don't even initialize the tool again, if it already exists.
>        # MY PATCH BELOW
>        if tool_class is None:
>            del setup_tool._toolset_registry._required[tool_id]
>            logger.info("Required tool %s does not exist. removed",
> tool_id)
>            continue
>        # /MY PATCH
>        if existing is None:
>        ...
>
> And I can install again new things in the site.
>

fantastic!

it's been a long time since i was actually dealing with these specific
issues, so i don't begin to have the context to judge whether there might be
other consequences that need to be accounted for, here.  it applies in the
realm of uninstallation problems where plone has some terrible pitfalls,
though, and deserves substantial attention - fixes are needed, and this may
have some part of the solutions.

what i guess i'm trying to say is, can those close to plone's core
development shed any perspective on this approach, and the problem it
addresses?

it would seem to me to suggest that there are logistical holes in generic
setup's maintenance of its required tools bookkeeping.  perhaps it's not
possible to provide for suitable adjustment on all types of updates, or
perhaps just a little code is needed to fill in some gaps.  might there be
ways that dependency chains could be broken by gilles' workaround, above, or
would it be safe to make that the standard conduct - or somewhere in
between, provide some accounting interface?  what's the situation?  some
greater exposure of the add-ons dependency provisions might be needed...

in any case, it's very helpful to have this info, to resort to in
emergencies.

ken

The patch can be removed afterwards since this cleans up the required tool
> from stuff that has been removed (uncleanly ?) from the file system.
>
> Cheers
> --
> Gilles Lenfant
>
>
> >
> > Cheers,
> >
> > --
> >
> > Gil Forcada
> > C/Llacuna, 166 2n.2a (Edifici Llacuna)
> > telf: 93.188.88.12 - 619.65.34.92
> > fax: 93.320.93.97
> > (08018) BARCELONA
> > gil at usecm.com
> > www.usecm.com
> >
> >
> > _______________________________________________
> > Product-Developers mailing list
> > Product-Developers at lists.plone.org
> > http://lists.plone.org/mailman/listinfo/product-developers
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-product-developers/attachments/20110906/db3083e5/attachment.html>


More information about the Product-Developers mailing list