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

Gilles Lenfant gilles.lenfant at alterway.fr
Wed Sep 7 11:48:08 UTC 2011


2011/9/6 ken manheimer <ken.manheimer at gmail.com>

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

Hi,

I didn't test much this patch. This resolved MY particular issue - after
checking that the ghost tools are not in the real requirements anymore - but
I don't know if this could or not hurt in other situations. This would
require more testing scenarios.

That's why I removed this patch immediately after the purge of the required
tools registry.

Cheers
-- 
Gilles



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


-- 
-- 
Gilles LENFANT
Ingénieur avant-vente - Architecte senior
ALTER WAY SOLUTIONS
T : 01 78 15 24 00
F : 01 46 02 44 04

Téléchargez notre nouveau livre blanc "Python, le développement autrement"
http://www.alterway.fr/publications/python-le-developpement-autrement

1 rue Royal, Bat. D
227, les Bureaux de la Colinne
92210 Saint Cloud
http://www.alterway.fr/solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-product-developers/attachments/20110907/5e3d8220/attachment.html>


More information about the Product-Developers mailing list