<br><br><div class="gmail_quote">2011/9/6 ken manheimer <span dir="ltr"><<a href="mailto:ken.manheimer@gmail.com">ken.manheimer@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div><div></div><div class="h5">On Tue, Sep 6, 2011 at 1:56 PM, Gilles Lenfant <span dir="ltr"><<a href="mailto:gilles.lenfant@alterway.fr" target="_blank">gilles.lenfant@alterway.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
Le 5 sept. 2011 à 20:34, ken manheimer a écrit :<br>
<div><div></div><div><br>
> On Mon, Sep 5, 2011 at 1:35 PM, Gilles Lenfant <<a href="mailto:gilles.lenfant@alterway.fr" target="_blank">gilles.lenfant@alterway.fr</a>> wrote:<br>
><br>
> 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.<br>




><br>
> Even removing the footprint of that f...g ghost component does not work/<br>
><br>
> del site.portal_setup._toolset_registry._required['foo_too']<br>
><br>
> 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.<br>
><br>
> Many thanks by advance for any pointer.<br>
><br>
> 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.)<br>




><br>
> here's the posting, with full context - hope it's helpful.<br>
><br>
> ken<br>
><br>
> ---------- Forwarded message ----------<br>
> From: Gil Forcada <<a href="mailto:gil@usecm.com" target="_blank">gil@usecm.com</a>><br>
> Date: Mon, Jan 17, 2011 at 2:25 PM<br>
> Subject: Re: [Product-Developers] How to cleanly remove a product?<br>
> To: Dylan Jay <<a href="mailto:djay@pretaweb.com" target="_blank">djay@pretaweb.com</a>><br>
> Cc: "<a href="mailto:product-developers@lists.plone.org" target="_blank">product-developers@lists.plone.org</a> Developers" <<a href="mailto:product-developers@lists.plone.org" target="_blank">product-developers@lists.plone.org</a>>, derek <<a href="mailto:auspex@pointerstop.ca" target="_blank">auspex@pointerstop.ca</a>>, Rok Garbas <<a href="mailto:rok@garbas.si" target="_blank">rok@garbas.si</a>><br>




><br>
> 2011/1/17 Dylan Jay <<a href="mailto:djay@pretaweb.com" target="_blank">djay@pretaweb.com</a>><br>
> On 17/01/2011, at 3:06 AM, derek wrote:<br>
><br>
> On Jan 16, 11:16 am, Laurence Rowe <<a href="mailto:l...@lrowe.co.uk" target="_blank">l...@lrowe.co.uk</a>> wrote:<br>
> hvelarde wrote:<br>
><br>
> guys, is a very bad practice not to write uninstallers (and tests for<br>
> them) in your products.<br>
><br>
> Unfortunately it is almost impossible to write an uninstaller - as even<br>
> removing a persistent component registration does not remove all references<br>
> to that key.<br>
><br>
> I'm so thrilled to see that from someone I consider an authoritative<br>
> source!  "Almost impossible" probably explains why I've yet to find an<br>
> even half-way decent howto.<br>
><br>
> And for people who write packages as part of customer projects,<br>
> it is difficult to justify the time to write an uninstaller.<br>
><br>
> Exactly. I'd bite the bullet and try to write a good uninstaller if I<br>
> was making products for the general public, but for my one-off<br>
> customer projects it really doesn't seem worth the effort.<br>
><br>
> I think the<br>
> real solution to this is to make content import/export work work correctly<br>
> (getting close with transmogrifier) so that you can zap and recreate a site<br>
> complete with content.<br>
><br>
> Close, but still no cigar.  Dylan's done a good job with funnelweb, as<br>
> far as it goes, but there's still a major manual component in<br>
> importing content.<br>
><br>
> 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?<br>




><br>
><br>
> Ok, FINALLY after a week long looking after this I have them (hopefully) gone :)<br>
><br>
> The basic modus operandi was:<br>
> - add the offending products on the buildout<br>
> - run the buildout<br>
> - uninstall all products still installed<br>
> - force the generic setup code to run by reinstalling a module which has propertiestool (membrane for example)<br>
> - remove all the tools on the ZMI site root<br>
> - add an ipdb to GenericSetup/registry.py on listRequiredTools method (line 576 or so)<br>
>     [i generally use 'import pdb; pdb.set_trace()', but ipdb looks cool! klm]<br>
> - remove the offending products on the buildout and rerun it<br>
> - remove the products from ZMI -> Control_Panel -> Products<br>
> - remove the portal_setup missing steps (if any)<br>
> - force the generic setup code again and when it hits the ipdb remove the tools with a "del self._required['TOOL_NAME']<br>
><br>
> That way they are gone for good!<br>
><br>
> I hope it will be useful to someone.<br>
><br>
> Thanks for all the pointers and ideas!<br>
<br>
<br>
</div></div>Many thanks for all this.<br>
<br>
I have been much more radical than this.<br>
<br>
I inserted this in the Products.GenericSetup.tool module in function importToolSet around line 123 :<br>
<br>
        ...<br>
        existing = getattr(aq_base(site), tool_id, None)<br>
        # Don't even initialize the tool again, if it already exists.<br>
        # MY PATCH BELOW<br>
        if tool_class is None:<br>
            del setup_tool._toolset_registry._required[tool_id]<br>
            <a href="http://logger.info" target="_blank">logger.info</a>("Required tool %s does not exist. removed", tool_id)<br>
            continue<br>
        # /MY PATCH<br>
        if existing is None:<br>
        ...<br>
<br>
And I can install again new things in the site.<br></blockquote><div><br></div></div></div><div>fantastic!</div><div><br></div><div>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.</div>


<div><br></div><div>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?</div><div><br></div><div>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...</div>


<div><br></div><div>in any case, it's very helpful to have this info, to resort to in emergencies.</div>
<div><br></div><font color="#888888"><div>ken</div></font></div></blockquote><div><br>Hi,<br><br>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.<br>
<br>That's why I removed this patch immediately after the purge of the required tools registry.<br><br>Cheers<br>-- <br>Gilles<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The patch can be removed afterwards since this cleans up the required tool from stuff that has been removed (uncleanly ?) from the file system.<br>
<br>
Cheers<br>
--<br>
<font color="#888888">Gilles Lenfant<br>
</font><div><div></div><div><br>
<br>
><br>
> Cheers,<br>
><br>
> --<br>
><br>
> Gil Forcada<br>
> C/Llacuna, 166 2n.2a (Edifici Llacuna)<br>
> telf: <a href="tel:93.188.88.12" value="+33931888812" target="_blank">93.188.88.12</a> - <a href="tel:619.65.34.92" value="+33619653492" target="_blank">619.65.34.92</a><br>
> fax: <a href="tel:93.320.93.97" value="+33933209397" target="_blank">93.320.93.97</a><br>
> (08018) BARCELONA<br>
> <a href="mailto:gil@usecm.com" target="_blank">gil@usecm.com</a><br>
> <a href="http://www.usecm.com" target="_blank">www.usecm.com</a><br>
><br>
><br>
> _______________________________________________<br>
> Product-Developers mailing list<br>
> <a href="mailto:Product-Developers@lists.plone.org" target="_blank">Product-Developers@lists.plone.org</a><br>
> <a href="http://lists.plone.org/mailman/listinfo/product-developers" target="_blank">http://lists.plone.org/mailman/listinfo/product-developers</a><br>
><br>
<br>
</div></div></blockquote></div></div><br>
</blockquote></div><br><br clear="all"><br>-- <br><span></span><span></span>-- <br>Gilles LENFANT<br>Ingénieur avant-vente - Architecte senior<br>ALTER WAY SOLUTIONS<br>T : 01 78 15 24 00<br>F : 01 46 02 44 04<br><br>Téléchargez notre nouveau livre blanc "Python, le développement autrement"<br>
<a href="http://www.alterway.fr/publications/python-le-developpement-autrement" target="_blank">http://www.alterway.fr/publications/python-le-developpement-autrement</a><br><br>1 rue Royal, Bat. D<br>227, les Bureaux de la Colinne<br>
92210 Saint Cloud<br><a href="http://www.alterway.fr/solutions" target="_blank">http://www.alterway.fr/solutions</a><br>