Product depencencies: trigger reinstallation

I'm developing a product for Plone, say foo.core. Besides that core product, there are also several related products. like foo.optional. These releated products may be available in the instance and if they are available they may be installed (in other words: I cannot assume the code is available or, if it is, should be used).

These related products may override settings made by foo.core (e.g. in a Property Sheet). This works fine, but if I reinstall foo.core, the default settings are back. What I'd want is to somehow automatically reinstall foo.optional when foo.core is reinstalled in the QuickInstaller.

The solutions I could come up with are:

• When foo.optional is installed, it registers itself with foo.core. The latter, foo.core, will handle the reinstallation of all registered products when the core package is reinstalled.
• The foo.core package triggers an event which other packages, like foo.optional, can listen for. An event handler will then trigger the reinstall of foo.optional.
• Make sure that foo.core doesn't overwrite any settings that may have been customized later by other products.

Perhaps there are more alternatives? What would be the 'Plonish' approach?

Edit: I know that using upgrade steps might be better than reinstalling the product. However IMHO the problem remains the same: the Generic Setup profile used for the upgrade step might have a setting that is modified in the Generic Setup profile for the foo.optional package.

So using upgrade steps makes my problem even harder: how should I determine whether the upgrade step of foo.core means foo.optional should be reinstalled/upgr开发者_StackOverflow社区aded? (The assumption is still that foo.core in principle does not know about foo.optional.)

The solution to your problem is much easier than what you propose:

We do NOT reinstall products like we did in the past when the product is updated. Reinstalling a product will cause your generic setup profile to be reapplied which is why you get your settings overwritten.

Instead you now provide upgrade steps. For instance if you change your profile version from 2 to 3 then you would have:

<genericsetup:upgradeStep
  title="Upgrade foo.core from revision 2 to 3"
  description="Adds stuff"
  source="2"
  destination="3"
  handler="foo.core.upgrades.two_to_three.addStuff"
  sortkey="1"
  profile="foo.core:default"
  />

Inside the upgrade step you can do what you like, even re-run individual import steps.

If your product upgrade does not involve changing the GS profile, do not increment the version in metadata.xml. In that case you obviously don't need an upgrade step either.

I suspect you are making things much harder on yourself by involving Plone's add-on installation story (which is complicated by "old" and "new" technologies living side by side). I would take a step back and think more about the plugin system you are trying to design/implement, and avoid including Plone until you absolutely have to [1].

You also might consider using entry points to implement at least a portion of the plugin system:

• http://wiki.pylonshq.com/display/pylonscookbook/Using+Entry+Points+to+Write+Plugins

[1] Assuming Plone is a strict requirement and that you are building a content-management-driven application, else you should probably be using Django or Pyramid

Install/reinstall doesn't make sens in the context of an add-on. The vocabulary has been change to activate/unactivate but it is not again enough to understand the situation.

You have a 'setup' where you apply a configuration profile. Apply again and again a configuration profile doesn't make anything except broke existing configurations.

This is why every body will reply to this question by use upgrade step. We don't trigger profile on reinstall, we upgrade add-ons when the setup profile has some changes.

So if you are in a case where settings added by foo.core are changed by foo.optional you can do the following.

With the new plone.registry you can add a handler to the IRecord related events:

• add
• edit
• remove

Consider the documentation:

http://pypi.python.org/pypi/plone.registry

I have done some code related to this where I want to rebuild css registry when some settings has been changed:

https://github.com/collective/collective.jqueryuithememanager/blob/master/collective/jqueryuithememanager/registry.py