2011/9/6 ken manheimer <[email protected]> > On Tue, Sep 6, 2011 at 1:56 PM, Gilles Lenfant <[email protected] > > wrote: > >> >> Le 5 sept. 2011 à 20:34, ken manheimer a écrit : >> >> > On Mon, Sep 5, 2011 at 1:35 PM, Gilles Lenfant < >> [email protected]> 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 <[email protected]> >> > Date: Mon, Jan 17, 2011 at 2:25 PM >> > Subject: Re: [Product-Developers] How to cleanly remove a product? >> > To: Dylan Jay <[email protected]> >> > Cc: "[email protected] Developers" < >> [email protected]>, derek <[email protected]>, Rok >> Garbas <[email protected]> >> > >> > 2011/1/17 Dylan Jay <[email protected]> >> > On 17/01/2011, at 3:06 AM, derek wrote: >> > >> > On Jan 16, 11:16 am, Laurence Rowe <[email protected]> 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 >> > [email protected] >> > www.usecm.com >> > >> > >> > _______________________________________________ >> > Product-Developers mailing list >> > [email protected] >> > 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
_______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
