I have recently mostly rewritten the drush module (drush = the Drupal shell). It was originally written by Arto for Drupal 4.7, but never really got out of beta stage back then.

Now, we currently have drupal.sh in core, which allows us to invoke index.php from the command line. drupal.sh is basically just a tool that allows to simulate HTTP requests over the command line. drush, instead, provides a (very simple) API for modules to expose command-line functionality. Any module can implement hook_drush_command() and return an array of commands (an implentation of hook_drush_command looks actually quite similar (though simpler, of course) to the D6 hook_menu). E.g. from drush.module:

/**
 * Implementation of hook_drush_command().
 */
function drush_drush_command() {
  $items['help'] = array(
    'callback' => 'drush_callback_help',
    'description' => 'View help. Run "drush help command" to view command-specific help.'
  );
  return $items;
}

The drush sets up the required $_SERVER vars (as drupal.sh does), parses the arguments into options and commands and dispatches the commands to their callback functions, as defined in hook_drush_commands. Additional commands are passed as arguments.

Now, the drush module has these files at the moment:
- drush.php - the CLI script that gets executed. Sets the required $_SERVER vars, parses the arguments and bootstraps Drupal.
- drush.inc - command dispatcher and helper functions (wrapper functions for calling disruptive functions and shell executions to allow a simulation mode, table generator, ...)
- drush.module - provides the usage instructions and also the help command, which outputs command-specific help via hook_help()

So, drush.module itself doesn't provide any actual functionality. There are currently two modules that implement the drush API, drush_tools.module with some utilities for admins and developers, like running cron or clearing the cache, and drush_pm.module, the drush Package Manager, which allows to install and update modules from the command line.

Now, IMO trying to move the basic drush API into core would be great thing. Do others feel the same?
However, I'm a little unclear on how/where would be best to integrate it in core (that's why there's no patch yet) - we could just add the drush module and put drush.php (the executable script) into scripts/. We could also try to build upon drupal.sh, however, as I said the conepts differ quite a lot, and I don't think that it would be desirable to build the drush API upon the existing drupal.sh. We could also try to move the functions in drush.module to drush.inc and just put it into includes/. Hmmm...

Setting to Code needs work - existing code is in contributions/module/drush (currently for D5, but should be working on HEAD after adding core=6.x to the info file).

I don't have much time to work on this in the upcoming two weeks (if any), but I think I could do one patch that ports the current drush API to D6, and then do some more work in the week before the freeze. I'd really like to get a hint of a core commiter or anyone else high-profile, though, wether this is "wanted functionality", or likely to be commited after some reviewing/tweaking, for D6, because otherwise, I'd better like to invest my time in other core tasks or in drush as a contrib module, and possibly reopen this issue for D7).

Files: 
CommentFileSizeAuthor
#1 drush-01.patch17.17 KBFrando

Comments

Frando’s picture

Assigned: Unassigned » Frando
Status: Needs work » Needs review
FileSize
17.17 KB

This patch would add just the drush API (without adding a new module).
The API functions are placed in drush.inc in includes/, the executable drush.php in scripts/.
The help command is moved to drush.inc (was in drush.module in the current 5.x implentation) and hard-coded in the commands array.

To test just apply the patch and then run drush.php (doesn't matter wether you run it from the Drupal root dir or from scripts/).

To look at an API implentation (and test the API) get the drush_tools.module from CVS (contributions/modules/drush) and enable it (you have to add core = 6.x to the ini file).

moshe weitzman’s picture

Assigned: Frando » Unassigned
Status: Needs review » Needs work

great to see this kickoff post. i just discovered drush and am very impressed. would love this in core. but, how to get there.

i think drupal.sh is a great basis and we should expand upon it. i might be missing something, but i think all the hook_drush_command() commands can be simply become standard menu callbacks. we need some supporting pieces:
- some extra menu param like 'cli_help'. the presence of this param indicates that the item should show up on the list of available commands. also, it is some usage help
- we might need to solve the "output format" issue that nedjo is working on at http://drupal.org/node/145551. we will want all these commands to return plain text. so these callbacks will have an extension of .text (see comment #18).
- enhance drupal.sh so it can "locate_root" just like drush, and some other niceties like specifying a user with -u command line arg.
- probably more.

kbahey’s picture

Frando, great work.

There are 2 ways we can do this:

1. For D6, we just need to replace drupal.sh with drush (can keep the drupal.sh name).

If we can get the drush pm (packet manager) stuff in, it would be great, but given the freeze is in 2 weeks, I am not sure if that is too ambitious or what. drush pm is an interface to update_status so packages can be pulled from drupal.org and installed from the command line.

2. Wait until D6 is out and then get the whole drush in core for D7.

Eventually, I like to update drupal the Debian way : drapt update && drapt upgrade! Also, it is just like pecl/pear command line.

Exciting stuff.

sun’s picture

Like moshe, I'd vote to enhance drupal.sh with drush functionality. drupal.sh basically works for most devs and site admins and the extended functionality provided by drush should stay optionally on top of it - maybe by enabling the drush module first.

IMHO another issue is code size. Since we are heading towards loading only necessary code on all requests, drush enhancements for drupal.sh should not have to be loaded f.e. in hook_menu(). Since all code for drush won't be executed in regular HTTP requests, I'd vote for having drush load all needed Drupal framework files dynamically.

chx’s picture

Version: 6.x-dev » 7.x-dev

Feature..

lambic’s picture

Status: Needs work » Needs review

should this still be open now drush sits outside the drupal webroot?

moshe weitzman’s picture

Status: Needs review » Postponed

not an active effort now.

moshe weitzman’s picture

Status: Postponed » Closed (won't fix)

Not happenning. Way too hard. drush and drupal are different open source projects, to be honest.