Consider broadening the module#enable() API

Looks like the installer tools are injecting the various states into the API so yeah, should be done re: the IdP.

I think the work items here are

• To add sub tasks for each plugin. This will require rolling the plugin min IDP to 5.2 so may be less than ideal

• To do the work for the IdP plugins.

In all cases this feels like something we will only need when we need it (a specific file has a specific need which depends on know what is going on outside).

So maybe we can mark this as resolved?

I’ve done the infrastructural changes. I’ll leave this unassigned for someone to pick up and make changes to the module implementations as the mood takes them

I think the crux of what I was after was to think about how to make the implicit behavior of the installers known to the module steps so they know what’s really going on in special/weird cases.

That way they can tell how to clean up files in certain edge cases without us needing to be really super careful about how we define resources if we change module IDs.

OK. So a break for lunch and some contemplation has persuaded me that I am conflating two very different things

• What is the user doing? (plugin install, plugin upgrade, install, plugin uninstall, command line).

• If this is an installer is this an initial enable or a reenable as part of the standard upgrade.

The first very obviously goes into the context, the second may not be knowable and is done per module (so in an upgrade there may well be a mix of enable and re-enable). I think that this goes onto (a second, defaulted) enable call.

At this stage I do not completely grock where each might be useful, but I was going mad trying to conflate two orthogonal issues.

I’ll do the installer/api side of this and we can loop back and see how to use it