running drush command without module installed
| Project: | Module Builder |
| Version: | 6.x-2.x-dev |
| Component: | Drush support |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
The aim is to have module builder downloaded only once, but usable by drush in any site on your system.
There are a number of pitfalls and things to be resolved. I'm kicking things off here in the hope interested people may have ideas.
First, where to put the MB command file?
Drush docs says:
You can put your drush command file in a number of places:
- In a .drush folder in your HOME folder. Note, that you have
to make the .drush folder yourself.
- Along with one of your existing modules. If your command is
related to an existing module, this is the preferred option.
- In a folder specified with the include option (see above).
- In /path/to/drush/commands (not a Smart Thing, but it would work).Making a .drush folder is tedious, and I don't like the unix tradition of a million dot folders in your home. That's out.
Option 2 is out, as that's what we want to move away from.
Option 3 requires configuration of your drush command alias or of a drushrc.php file.
Option 4 is advised against -- upgrades of Drush would wipe your mb folder.
Looks like it's option 3: configure your drush to point to one of your drupal installations' mb/drush folder.
Problem 2 is where to store the data mb needs to download. Without a drupal instance, we don't have a a files folder.
We could just create a subfolder in mb for downloads, but then of course that gets clobbered on upgrade too. But you'd just have to download them again (command for doing that is pending...).
On the other hand, if we're sitting within a drupal install, we can find a files folder (in theory: it might be a totally fresh uninstalled drupal).
Problem 3 is forking. I don't want to have to maintain 2 modules, one for drush and one for drupal.
So some refactoring of code is going to be needed so drush has access to functions for downloading hook data, processing it, and also hook templates.
Thoughts, ideas?
#1
Some further pitfalls:
- how do we get hold of the constants that set module header code and the like?
- where do we store downloaded hook data and how do we get it?
#2
Also, wherever we store hook data, it has to be per-core version.
And when we load hook data, we have to tell the loading function which version we want.
And we need several versions of the entire module if drush is to support several versions of core as the templates will be different.... ouch.
#3
This is well on the way to being done:
- runs with the module folder placed outside of Drupal
- stores hook data in the current Drupal install.
Todo:
- store hook data centrally
- support for different core versions
#4
This now works.
Downloaded data is still saved in the local drupal install.
Allowing this to go in a common folder is on the todo list.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.