do not load everything and provide a way to tell drush what to load
| Project: | Drush |
| Version: | All-Versions-HEAD |
| Component: | Interoperability |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | 2.0 |
Jump to:
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.
#1
Tagging for 2.0.
#2
still needed?
#3
#4
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...
#5
If anyone wants this in 2.0, better submit a patch soon.
#6
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.
#7
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.