Right now in Provision, we have experimental modules we do not want the backend to load. For example, DNS and ITK provisionning are experimental if not completely broken. So we don't want those to load, by default. If the frontend (hosting module) decides it should try to enable that feature, then it's going to add a --load-itk or --load-dns argument to the drush call.

Before provision was a module, and it was just matter of disabling it in the Drupal web interface. Now that it's a drush extension, we need to be able to tell drush to enable/disable it.

Our thoughts are that things should be disabled by default and loaded only if asked for. Or maybe the drush modules could declare that status themselves (loaded by default or not).

At any rate, this is required to complete the #349923: drush_invoke : a flexible API for hooking into any and all drush calls. move.

Comments

anarcat’s picture

anarcat commented
Issue tags: +2.0

Tagging for 2.0.

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Postponed (maintainer needs more info)

still needed?

moshe weitzman’s picture

moshe weitzman commented
Priority: Critical » Normal
anarcat’s picture

anarcat commented
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Needs work

Yes, this is still necessary. I'm not sure whether the current code has hooks to do that, but we will need something like this because there are features that should be active (or not) on the backend depending on the admin's selections on the frontend. DNS and inter-site security (ITK) are the obvious candidates, but those will expand as needed.

It feels like reinventing the wheel, but it can be pretty simple too. At some point in provision, there was a --load-something command (i don't remember the syntax) that would load the proper modules in the backend...

moshe weitzman’s picture

moshe weitzman commented
Priority: Critical » Normal

If anyone wants this in 2.0, better submit a patch soon.

reikiman’s picture

reikiman commented

FWIW this seems related to #468650: Drush attempts to call hooks for disabled modules where I argue it's strange for drush to be making available commands from disabled modules.

adrian’s picture

adrian commented

Reikman: you're correct.

We've decided to tackle this in the next release of Drush tho, as we've just removed the optional modules from our tarball.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs work » Fixed

IMO this was fixed recently.

greg.1.anderson’s picture

greg.1.anderson commented

Not fixed, but now a duplicate of #691174: Allow drush command files to define functions that control whether or not they will be loaded?

anarcat’s picture

anarcat commented
Status: Fixed » Closed (duplicate)

I do think that the "named context" stuff could answer the requirement here. The basic idea here is that we need a way to have some hooks *not* enabled by default and enable them through some options.