[Product-Developers] State of uninstall addons in Plone

Jean-Michel FRANCOIS toutpt at gmail.com
Sat Apr 28 20:35:41 UTC 2012


@Maurits van Rees
Thanks for your feedback and quote from Hanno. I'm agree with Hanno and
interested by your addons.

I will soon publish mine about cleanup some stuff let by addons in Plone.

@lucca
> What I think that is missing is something like this:
> ...
>What I mean is something that do not re-run dependencies profiles if
> the profile is already installed.

I think this is wrong because profile are not install, they are all about
configuration snapshot/state. Means when you are adding dependency tag you
mean "apply the configuration state needed to myaddons to work". So if this
confiugration was already changed, you changed will be just removed because
you have specify to apply plone.app.imaging to work.

I often read the profile before apply it to know what configuration will be
applied. When site are already in production you can have many changes you
don't want.

Back to topic:
So there is no 'install' or 'reinstall' terms. With generic setup this is
all about configuration of Plone. This is why the uninstall usecase is so
weird.

Install means:
* add the egg to the system
* load the zcml (components) in the system
* configure your components using Plone tools (registry, css, js, types,
actions, ....)

uninstall means:
* remove anything from the DB that is persistent data from your addons
(import_step.xml, components.xml, used views in your site, ...)
* "UNCONFIGURE" stuff from your plone site (allmost achieved by quick
installer except for some steps)
* remove it from the system
* try to restart and tests if everything are working

So the best behavior for the 'uninstall' button in quickinstaller should be
to 'unconfigure' every steps that genericsetup has configured while
instaling AND updated the addon !?

The best way to achived this at the moment is to create
Extensions/Install.py with uninstall method in it and achieved the gap from
what quickinstaller already achieved and DO NOT use an 'uninstall' profile
which do not make sens.

Regards / Cordialement,
JeanMichel FRANCOIS
Find me on Twitter <http://twitter.com/toutpt> / Retrouvez moi sur
Twitter<http://twitter.com/toutpt_nantes>




2012/4/28 Luca Fabbri <luca at keul.it>

> On Thu, Apr 26, 2012 at 8:00 PM, Maurits van Rees
> <m.van.rees at zestsoftware.nl> wrote:
> > Op 26-04-12 14:11, Héctor Velarde schreef:
> >
> >> On 26/04/12 05:42, Maurits van Rees wrote:
> >>>>
> >>>> Should we make QI support "uninstall" profile ?
> >>>
> >>>
> >>> Yes. There is a ticket here, which might need to be turned into a PLIP:
> >>> https://dev.plone.org/ticket/11328
> >>
> >>
> >> HV> this came from a talk Cris and I had almost 18 months ago (yes,
> >> Cris, I know I never seconded you on that, sorry)...
> >>
> >> I think the problem is a little bit more complex as Hanno pointed out in
> >> this thread:
> >>
> >>
> http://plone.293351.n2.nabble.com/Apparent-bug-in-Products-CMFQuickInstallerTool-td5814226.html
> >>
> >>
> >> this is from Hanno's first answer:
> >>
> >> "Well, "uninstall profiles" are an invention of some people that has no
> >> real technical basis. There's never been support for them and I'm not
> >> aware of any PLIP or core documentation that advertises them.
> >> Specifying a second profile for your product actually is a bit
> >> dangerous, as quick installer picks the first profile it finds for a
> >> product and uses it as an install profile. There's no stable ordering
> >> of the profiles, so it could just as well pick the uninstall profile
> >> as an install profile. Technically there's only base, extension and
> >> upgrade profiles. There's no technical difference between an extension
> >> profile with a name "default" and one with a name "uninstall". I think
> >> these days both of these might show up as installable add-ons on the
> >> add-ons control panel."
> >>
> >> end of quotation...
> >
> >
> > As far as I am aware, currently the profile names are sorted in
> alphabetical
> > order.  The order might be different on different operating system
> though.
> >  For example, 'Final' with upper case F may be sorted before or after
> > 'default' with lower case d.  As long as your profile names start with a
> > lower case character, the ordering should be the same everywhere.  The QI
> > picks the first one, so with 'default' and 'uninstall' this will always
> be
> > 'default'.
> >
>
> Yes, but this is really bad in my opinion.
> There is around at least one product (collective.flowplayer) that
> added a profile called "basic" that unluckily take precedence over
> "default". Every Plone user that try to install flowplayer see in the
> QI the "Flowplayer setup without type" that is not commonly what users
> wants.
>
> Also: I think that another feature is missing: dependencies profiles
> in metadata.xml are good, but sometimes they can blow up you
> configuration.
> An example: recently we removed the "plone.app.imaging" dependency
> from redturtle.video because when you already have p.a.i installed in
> your Plone site (as default on Plone 4, but not on Plone 3)
> reinstalling it's profile will erase all user defined image size.
>
> I used as example redturtle.video but I'm sure we can find a lot of
> other examples for Plone 4 only products. There are few products that
> take care on this, for example: if you reinstall PloneFormGen it not
> delete all user defined additional field or adapters.
>
> What I think that is missing is something like this:
>
> <?xml version="1.0"?>
> <metadata>
>  <version>1000</version>
>  <dependencies>
>    <dependency
> skip-if-installed="True">profile-plone.app.imaging:default</dependency>
>  </dependencies>
> </metadata>
>
> What I mean is something that do not re-run dependencies profiles if
> the profile is already installed.
>
>
>
> > I think the only profile names I have ever used, are default, initial,
> > test/testing and uninstall.  That has worked fine as far as I remember.
> >
> >
> >> HV> my latest tests with Plone 4.1.5 show that probably the only thing
> >> you need to put on your uninstall profile is a registry.xml file.
> >>
> >> previously we needed also a browserlayer.xml but Maurits fixed that
> >> recently.
> >
> >
> > I am not aware that I did anything here, but I tend to forget stuff like
> > this. :-)
> >
> >
> >> HV> and it get worst: if you want to remove records from
> >> plone.app.registry you will have to use things like this:
> >>
> >>
> >>
> https://github.com/collective/collective.googlenews/blob/master/collective/googlenews/profiles/uninstall/registry.xml
> >>
> >>
> >> so now we have "remove=true" and "delete=true"...
> >
> >
> > Indeed, it totally depends on how the underlying import step is written.
> >  Some code may simply ignore any 'remove' or 'delete' options and add the
> > item anyway.  And some code may see 'remove=False' and think: ah,
> 'remove'
> > has been specified, so let's remove this item.
> >
> >
> >> resuming: how do you deal with uninstalling packages? it depends on what
> >> Plone version you're running; use Extensions/Install.py uninstall
> >> methods, write tests, and remove anything unneeded.
> >
> >
> > Indeed.
> >
> >
> >
> > --
> > Maurits van Rees: http://maurits.vanrees.org/
> > Zest Software: http://zestsoftware.nl
> >
> > _______________________________________________
> > Product-Developers mailing list
> > Product-Developers at lists.plone.org
> > https://lists.plone.org/mailman/listinfo/plone-product-developers
>
>
>
> --
> -- luca
>
> twitter: http://twitter.com/keul
> linkedin: http://linkedin.com/in/lucafbb
> blog: http://blog.keul.it/
> _______________________________________________
> Product-Developers mailing list
> Product-Developers at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-product-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-product-developers/attachments/20120428/ebf49bca/attachment.html>


More information about the Product-Developers mailing list