Drush does NOT have to be a module!

Sure, we've all been interested in this for a long time.

A few tips:

* next time, please try to be brief in your description.
* please make a new module.inc file which holds functions like drush_module_implements(). that way we can see how the new module engine works.

This is looking very interesting. I'll give it a test when I get a chance. I hope others do too. Meanwhile, please include any documentation changes that are needed (README, example.drushrc.php?). Also, the glob() function is not universally available. D7 just remove it in favor of some workaround - i don't recall the details.

This is exciting. Most things allready work smoothly. After I changed module_invoke_all to drush_module_invoke_all in the drush_pm_module, I could even install packages into my drupal 6 directory while running drush from a directory in my home dir. Very nice and this way the drush_pm module can get rid of the requirements hook. Or change this to our own requirements hook to check if a module is enabled on the site we are looking at, because things won't work if simpletest module isn't installed for instance. I'm going to play with it more and try to update the patch to see what needs to be changed more.

I love the patch so far.

I'm busy finishing up a version of the patch here.

The mask is far too restrictive, and glob is not the right function to use.

In the patch i am finishing up, I copied file_scan_directory, so we can have nested searches.
I have changed it to load *.drush.inc files (instead of the module files), and I am busy moving all the actual commands into their own .drush.inc files (this is easy, but slightly time consuming).
I also added a --include or -I option, that allows you to specify additional search paths to find drush commands.

I've actually got this working for installing sites using aegir (groups.drupal.org/aegir). We are by far the most complex users of drush, and this patch makes our lives a _LOT_ easier.

Here is the patch as promised :

1. Drush now loads *.drush.inc files
2. You can specify additional paths to search using -i or --include (documentation has been updated too)
3. All module files are split into MODULENAME.drush.inc and MODULENAME.module files. (the .module files might become irrelevant if we decide to ignore the hook_help implementations).

I support the extensions that Adrian has added. Nice work. I'd love to see:

* README.txt updated
* Someone has to commit to updating HEAD. We can't let that fall behind for very long. I'm much less concerned about backport to 5. If someone wants to do that, then I'll commit it in a new branch but it really isn't needed IMO.

This looks really good!

I started testing it out, but realized that module.inc is missing from adrian's patch. Rather than starting from the one in the previous patch and trying to deduce the changes I figured it would be quicker to just reroll.

Some thoughts/questions:
1) Am I right in assuming that if modules implement drush commands they will still be available via the regular hooks as long as that site gets bootstrapped? I think this would be very useful for commands that are part of some more complex general purpose system that you might not want on every site.
2) If (1) is the case then am I correct that if you wanted to add a module to your "system" drush installation you could just copy it to somewhere below your drush directory?
3) If (3) is also the case then are there any helper functions we would need to write so that modules could operate correctly?
- How would dependencies be handled?
- What if the module needs some installation to work at all?
- Would modules just need to be specially written to support this (i.e. to operate mostly independently and check for any dependencies at runtime)?
- What happens if the code is both in the system drush directory, and also the site modules directory - how do we prevent it running twice?

The last actually has a more general case - what happens when I try and run the "system" drush on a site that already has drush installed in the old way - are we preventing it getting included twice?

Sorry about that, i only added Entries for the files I added. Didn't realize module.inc wasn't included.

I would have re-rolled , but my tree is not pristine right now. I used this patch as the basis for an experiment to see if i could make drush run in DRUPAL_BOOTSTRAP_CONFIGURATION. I added a 'bootstrap' level to the hook_drush_command structure, so you can specify the level to initialize at.

It worked. This patch is the first step in being able to write an install command for drush, which mimics the functionality of install.php.

Am I right in assuming that if modules implement drush commands they will still be available via the regular hooks as long as that site gets bootstrapped? I think this would be very useful for commands that are part of some more complex general purpose system that you might not want on every site.

not at present, we'd need to have our own implementation of system_listing to pick up commands in the enabled module trees. It would essentially add more directories to --include. I don't think there should be multiple places to add drush commands (such as either in .modules or .drush.inc), but the modules will be loaded as part of DRUPAL_BOOTSTRAP_FULL.

2) If (1) is the case then am I correct that if you wanted to add a module to your "system" drush installation you could just copy it to somewhere below your drush directory?

Yes. as long as you also specify the path in --include, either on the command line or the drushrc.php.

3) If (3) is also the case then are there any helper functions we would need to write so that modules could operate correctly?
- How would dependencies be handled?

Drush commands could check that the module they require exists. I suggest adding a 'depend' entry to drush_command, and make the help command respect that when showing available commands. This is a per command thing for me. Part of this would tie into the drupal_bootstrap level, so that if a site isn't initialized, it will only show commands available at the BOOTSTRAP_CONFIGURATION level.

- What if the module needs some installation to work at all?

Having the commands depend on modules being enabled would solve that.

- Would modules just need to be specially written to support this (i.e. to operate mostly independently and check for any dependencies at runtime)?

Well. at the very least, I think they should have a *.drush.inc if they want any drush commands whatsoever. I'm currently including the .drush.inc in the module file, so more complex systems could do the same.

- What happens if the code is both in the system drush directory, and also the site modules directory - how do we prevent it running twice?

As i mentioned, we should copy system_listing, to match how drupal detects what modules it is running. To stop multiple command sets from being loaded we will use the same mechanism Drupal uses, ie: index the files array with the basename, not the filename.

Anyway, this patch is important to the Aegir project. We were on the verge of dropping drush in the next release, because it simply requires too much to get up and running. You can't use it to install a site until you have at least one running, which meant for every
drupal release, you would need a database, and a virtual host configuration and manually go through the install, before you could use
it to deploy other sites.

This with the extension if being able to specify what level to run at while initializing, will allow us to write drush commands that can initialize and install sites, without having to load an initial site and then switch active databases (which is a really ugly hack to begin
with). I am actively maintaining Drupal 5 and Drupal 6 trees of provision (http://drupal.org/project/provision), but until i make a final 0.1 release of those projects, I can't contribute much time to a Drupal 7 version of this patch.

Perhaps we should consider this the start of a 2.x branch for drush ?

I really don't think allowing the drush_command hook be in multiple places is all that useful, especially since you would be in situations where you could want the code to be in multiple places, which would result in namespace conflicts.

And drush.inc files would be similar in nature to .install functions. IE: they could still be loaded from modules when needed, but wouldn't need to always be present.

So just to come up with a more solid example for us to get out heads around, lets think about coder module. This module has a pretty significant amount of code to do it's job, and most of it gets called from both the web interface and the drush command (and you would often want both interfaces available).

My understanding then is that you would copy coder.drush.inc from the modules folder into your drush folder or set up a drushrc for that site to include it. coder.drush.inc would then need some kind of check to see if the module was enabled before returning it's commands to drush.

I think that overall (if I have captured the workflow) this looks pretty good, although still raises a couple of questions.

I think it could be worth modules like these discouraging copying the file into the drush folder - that could cause problems because the drush module would still be per-site (because the user wants the web interface) and so if you upgrade one of your sites to a new coder version that changes the API then you have to either use that verisons coder.drush.inc (breaking when you use it on the old sites), or the old one (breaking on the new). Instead I guess part of the Drush installation would be to add an include parameter to the drushrc for that site, to include the coder.drush.inc for that site specifically.

Allowing modules to provide commands directly would avoid that step of updating each sites drushrc to include commands for each of the modules used on each site. I think that if you have a lot of sites and modules this could rapidly become tedious. One way around this (and perhaps this is what Adrian is suggesting) is for Drush (post full-bootstrap) to check each active module directory and auto-load a modulename.drush.inc file if it exists. How does this sound?

Oh. and when i mentioned the bootstrap stuff i made this the basis of, it also allows us to write a replacement for update.php.

My understanding then is that you would copy coder.drush.inc from the modules folder into your drush folder or set up a drushrc for that site to include it. coder.drush.inc would then need some kind of check to see if the module was enabled before returning it's commands to drush.

There would be no copying involved.

Drush would find all .drush.inc files available to the site (through the same method drupal uses to find modules to begin with).
The --include would be added to the end of this set of search directories.

Allowing modules to provide commands directly would avoid that step of updating each sites drushrc to include commands for each of the modules used on each site. I think that if you have a lot of sites and modules this could rapidly become tedious. One way around this (and perhaps this is what Adrian is suggesting) is for Drush (post full-bootstrap) to check each active module directory and auto-load a modulename.drush.inc file if it exists. How does this sound?

Yes. They would provide commands directly. The commands would just be stored in a modulename.drush.inc , not in the .module itself.

The drush_command hook would also be able to specify dependencies (ie: module x needs to be enabled for this command to be available).

And the commands would be able to specify which runlevel they execute on. IE: site installs and updates would run at DRUPAL_BOOTSTRAP_CONFIGURATION, and are thus available even when a site hasn't been selected.

Sounds perfect :)

Vingborg: I am the lead developer of the Aegir hosting system http://groups.drupal.org/aegir.

The system has 2 components, hosting (the front end) and provision (the back end). The back end can be run separately, and provides drush commands to install new sites (including generating virtual hosts and creating databases and soon nameserver provisioning), and many other things. It also fully supports install profiles and locales.

The front end provides a drupal based interface for managing these sites. Each action on the hosting interface, generates a task, which then gets mapped to a drush command on the correct platform (drupal release).

Currently we need to have a site with the provision module installed and enabled on each of the platforms, to be able to run it. I would prefer to have one provision module installed per server, and only have the provision_drupal module for each release used.

This is the major requirement of our second release (0.2). The third release will be doing all this across multiple servers through ssh tunnels.

I have many features bolted on to drush that I would like to move upstream for our next release (flexible error reporting and logging, a scripting layer for writing drush commands that are called by other drush commands and more).

If you'd like to chat sometime, you can find me on #hm2 on irc.freenode.net. I am Vertice.

Great. A few more requests

- Add docs for module.inc. I can just see developers looking at this and puking all over their keyboards. It is usually a fatal mistake to maintain copies of core functions in your module. We need to explain why we need our own module system.
- Add brief API docs to README so that a module developer knows how to provide command(s).

I will test this out tomorrow.

Also, I'd like to go all the way and remove the whole /drush_sql directory and just have an /includes/drush_sql.drush.inc (for example). that file should get recognized by the drush module automatically. it would scan the root and /includes directories of all modules for *.drush.inc. this is how views does it ... we'll need some way to provide the hook_help texts from within the include.

I want drush to be a model for all other modules in terms of how it ships its own commands. thats why i would like to follow the standard set by views, cck, og, and others. so, we ship with a folder called 'includes' and in there we ship with files called sql.drush.inc, pm.drush.inc, tools.drush.inc, etc. this file naming convention comes form module_load_include() so lets stick to it.

thanks for working on this.

I tested the 'ready to run' version and it is working flawlessly. Code review revealed minor nits which we can resolve later.

My only major question is our pervasive use of the word and the concept 'drush module'. One code comment illustrates the problem - "A drush module is a file that matches *.drush.inc". Huh? Lets call such a file a drush command file (feel free to propose alternatives). I'm not sure why vingborg wants to distinguish these from standard drupal code, but I am OK with calling these files 'sql.drush' (for example). That would be a happy return to v1 of this module (see http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/drush/servi...).

Also, consider that drush_module_list() scans for modules that end in drush.inc (or .drush is we go with my suggestion above). Perhaps we are doing ourselves a disservice by calling this file module.inc and re-using the module terminology. what about command.inc and command_list(), command_hook(), command_implements(), etc. Sorry vingborg - I know thats a royal pain in the neck. Lets discuss.

Adrian mentioned that there should not be multiple ways to provide commands and I sort of agree. That means that we should stop looking for commands in module files. We only consider *.drush files. I'm open for discussion on this.

It is interesting to consider that drush could work across drupal major versions, but ultimately i don't think we can take much advantage of it. We are committed to distributing this project on drupal.org which means we must conform to its CVS branches and module download pages. So I think we will just release this project in lockstep with drupal major versions as we always have.

Thanks for this great patch, vingborg.

I don't think that a new file extension is a great idea, I consider PHP and Drupals cluttering of the filename namespace excessive already – I have like half a dosen extentions set up to match PHP in my IDE.

I prefer name.drush.php, but name.drush.inc is also okay

How difficult would it be to write a patch to backport this to d5?

That's one of the primary reasons i didn't add another .drush extension (although i think it would be cleaner, personally).

*.php to me means it should be executable on it's own, i guess. (but then, i did create the *.tpl.php convention, so i'm on pretty shaky ground arguing for that :) )

Oh. and how about splitting off the stuff that requires specific drupal versions into different projects, and keeping the core drush in a state where all the branches are exact copies of each other? (ie: tag off head). There's nothing in any guideline i know of that forces people to write modules that aren't backwards (or forwards) compatible, or to be able to use them without actually having a drupal install.

That is something that can be pretty easily documented.

Oh. and how about splitting off the stuff that requires specific drupal versions into different projects, and keeping the core drush in a state where all the branches are exact copies of each other? (ie: tag off head). There's nothing in any guideline i know of that forces people to write modules that aren't backwards (or forwards) compatible, or to be able to use them without actually having a drupal install.

Thats a tempting proposal. Yet, I think almost all drush commands have changed over the d5-d7 span. Certainly drush_pm, drush_sql, drush_simpletest, watchdog vary across versions ... So we'd ship with a drush that could run cron and thats about it ... It would be interesting to ship with a command that could download the version specific commands for you. It would be a baby version of drush_pm.

@vingborg - drush_command_list() sounds good. personally i think *.drush files a /commands subdir is really clean. but for now i'm ok with sticking with *.drush.inc and /includes folder since thats what vingborg has.

A marker for commands that doesn't require a fully bootstrapped Drupal site. More on that later, but essentially I'm thinking about diagnostic tools and overall site management. OTOH, it might be taking it too far, for now. Adrian, you seem to have thought a lot more about this, so please advise.

I actually got this working previously.

I simply move the drush_bootstrap_drupal to the latest possible moment (after it's found it's command), and it was parameterized, so it would take the 'bootstrap' property of the command in drush_commands.

From that point onwards it's up to the drush command itself to manage the bootstrap level (if you look in install.php / update.php you will see what it does). If there isn't a bootstrap property, it simply did a DRUPAL_BOOTSTRAP_FULL.

There were a couple of tricks though :

1. you would need to include bootstrap.inc first to be able to use the constants, but this could be worked around by adding our own mirrored set of DRUSH_BOOTSTRAP_X levels.
2. you couldn't use t() on non bootstrapped commands, because that is only loaded when common.inc is loaded which is only at a specific bootstrap level.
   • This could potentially mean that you wouldn't be able to have one command.drush provide both BOOTSTRAP_CONFIGURATION and BOOTSTRAP_FULL commands, as alll the functions might not be available at lower levels.
   • You could also just rely on get_t() in your code, but that gets messy .. oooor you could just use st() in your code, which I think might be a sane solution for all drush commands to begin with (http://api.drupal.org/api/function/st/6)
3. Perhaps a dt() function of our own would be better, as st() seems to be hardcoded for install profiles, and we would probably want to be able to provide translations for command help that aren't available elsewhere. How do normal shell applications handle this stuff?

It's probably at this point you would add the dependency check, and only if it has done a DRUPAL_BOOTSTRAP_FULL.
My idea on the dependency checking was very simple actually. Just have a 'requires' array property, and it would do :

   
   if (DRUSH_BOOTSTRAP_FULL) {
      $status = TRUE;
      foreach ($command['requires'] as $module) {
         $status = $status &&  module_exists($module);
      }
      if (!$status) {
          print("E: a required module could not be found");
      }
   }

I wasn't even going to think about dependencies between 'drush command files'

Thanks for this improved version.

I'm waffling a bit on the commands folder. I like it in Drush, but thats about the only module that needs multiple *.drush.inc files. Most others will be coder.drush.inc or whatever. It would be more convenient for other modules to put *.drush.inc into its module root directory or a /includes subdirectory. So, could we please add those locations to the search path and update the docs? I'm willing to get rid of the commands folder and package ours in includes as well. Sorry for my indecision here.

I don't think it is feasible to keep one codebase across drupal versions. I don't like the idea of creating a separate version-specific project. So lets keep on distributing this as a full package, with all the command files.

Personally, I like a single README.txt file.

I'm willing to defer the dependency and bootstrap improvements that adrian discusses. Or Vingborg can tackle them now if he wants.

Third, commands that really does need t(), would always be site-level, so the t() would be jacked up and good to go.

The issue is that you can't even include .drush files that have t() if you don't have a bootstrapped site, as it will end with a php error.

I do think we can also handle the bootstrap stuff in a separate patch (which is where the t() issue comes in). but I'm growing on the idea of using a separate dt() function, which can look at the $LOCALE environment variable, which is the correct way to handle shell based translations.

Commands wouldn't be translated, only messages / help text.

Also, i've never liked the drush_print function, fwiw. I built a mechanism closer to drupal's output system that could use theme().

I love the concept! This is huge for Drush and moving toward modular, community-standard practices for rapidly deploying Drupal. I played the role of bumbling tester, notes at Agaric, because I do that well.

In short I can confirm that that it works for our main use, drush pm (installing and updating modules with package manager), now from outside of anything Drupal.

Are there project-level commands I should test with a site that isn't running?

^{benjamin, Agaric Design Collective}

Will this discover *.drush.inc files that belong to inactive modues? If so, thats pretty disconcerting. This could be fixed with dependencies as adrian suggested. is that the best way?

For limiting drush commands to active files, you might have a look at simpletest_get_all_tests(). See http://api.drupal.org/api/function/simpletest_get_all_tests/7

Also, I forgot to mention that core has a VERSION constant at top of system.module. No need to look at node.info

I just took a shot at this - now commands can pass an additional 'bootstrap' array element, and drush will only bootstrap to that level. I have moved the inclusion of bootstrap.php a bit earlier so we can use the regular constants. It defaults to DRUPAL_BOOTSTRAP_FULL, which is needed (AFAICS) for most of the core commands. I have also added a new DRUSH_DRUPAL_PRE_BOOTSTRAP, which prevents any bootstrap at all (even a valid configuration).

I also changed how drush_shutdown() works, because detecting a function in common.inc is not a sign of success in other bootstrap levels. Instead we simply set a global to indicate that we have come out of bootstrap successfully, and suppress the message.

I also added an (incomplete) dt() function and replaced some of the early t() calls with this (should probably do the others too). We should figure out what approach we want to use for this, and we can use this as a simple wrapper function.

I think that once we have cleaned this up a touch more, and made sure that the .drush.inc approach is the right one we should probably just commit this as a 2.x branch, which will allow us to work on this in more sensibly sized patches :)

I'm committed to making drush be version agnostic, if that means I need to fork it, so be it.

It's either that or write my own drush like tool and stop using drush entirely (which i was going to heavily consider for the next release of aegir had this patch not appeared).

OK, Sounds like there is strong interest in keeping drush version agnostic. I guess we would move most commands to a Drush commands project? Could we ship core drush with a command which will install the right version of this project? Is there some way to put pm install into the core distro? Thats probably wishful thinking. Anyone have a vision for this?

I agree that this needs a little more polishing and then we'll commit. I guess I would create a 7.x branch, and then put all the new files into HEAD. Is there some easy way to do all the adds and deletes? I'm thinking of what svn_load_dirs.pl does for SVN.

@adrian - the version dependency was an oversight on my part - not intended to be a design decision! Let's switch it out with something not dependent on bootstrap.php.

We can still ship everything with the core distro, but version specific ones will replace the core shipped ones when it loads a specific uri.

We will always need to ship a set of version specific commands, but the way that provision (the aegir backend is written), only the commands that actually need to load the site's db (install, update etc) will require a platform to work on. The rest will be stored outside.

I've just started working on merging the code bases for all the different revisions again, but what this will eventually mean, is you will only
need to update 1 module to support a new drupal release.

I spent last night breaking out the install stuff from drush, into it's own .php (that has an include that simulates some drush things) :
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/provision/p...

That will take an already configured settings.php and created db, and install drupal on it (with the parameters).

I use my scripting and logging layer for it, so anything changed / logged during the separate .php process gets merged into the final output.

That install.php file could be turned into a bootstrapless drush command pretty simply. I want to hack up an update.php using a similar method soon.

This issue looks very promising indeed. Great to see more people work on drush.

Regarding version agnostic vs. version specific, I'd propose to do the following:

In the drush directory in CVS, we create two subdirectories, e.g. named drush_core and drush_commands. drush_core would be the same across all CVS branches, containing drush.php, drush.inc and all commands that can be completely version agnostic. Everything in the drush_commands directory can be major version specific, i.e. differ between the branches.

The drush_core directory can also be moved completely out of the Drupal directory and be placed anywhere.

Whenever a command is invoked, the rule would be to check if a version specific implementation is available (i.e. a command implementation located with the site for which drush was invoked) and if not fall back to the version agnostic one (i.e. a command located with the drush.php that was executed), should it be there.

Making drush_pm completely version agnostic would involve quite some copypasting, as it relies on update_status.module/D5 resp update.module/D6. So to make it version agnostic we would most likely have to copy the xml and info file parser from update.module, which would be quite some code to maintain. An alternative could be to have a very limited and basic drush_pm in the version agnostic part of drush that basically can do nothing but install the most recent package of drush into the currently selected site (matching the major version of the selected site, thus then installing the matching version specific parts). So no info file parsing or update functionality would be needed, only parsing one xml file. As soon as the version specific drush is installed for a site, the full range of commands becomes available.

Thanks Frando.

What do others think about his suggestion to have two top level directories? One reason not to like it is that it differs from how Contrib and modules will supply commands. Is it important to be a model? Splitting drush into a 'Drush extras' at least prevents us from being a bad model. Just fishing for opinions here.

Yes, that very minimalist pm install is what I had in mind.

I'm starting to think we really need to have this patch land in some form so we can collaboratively work on it. It's simply grown far too large to manage solely in the patch queue.

Basically, we should create a DRUPAL-7--1 branch for what's in HEAD now, and apply a somewhat working version into HEAD that we can refine further and make DRUPAL-x--2 branches from once we've sorted out the issues.

For this we need to at least get the file layout right, so we're not constantly moving files about.

I just spent a few hours refactoring a local checkout of provision, in preparation for our 0.2 branch (which will depend on this patch),
I fixed most of the smaller issues i came across when trying to test this with the patch before.

so I should have a substantial code base to test all the edge cases of this soon (think: installing drupal from the command line, updating sites, making backups and restoring them, changing db servers, provisioning mysql user accounts and apache virtual hosts, and much more).

I also wrote a script to run update_x functions for d5/d6 (part of our 0.2 milestone), and there's some other interesting bits and pieces i want to play with such as using drush to actually check out a whole drupal tarball, download just the version specifics drush bits and install them, and then offering them up to you. I also want to try and make it so drush can be run on any platform you point it at, and it will initialize all the version specific bits for you.

I'm going to try and get as much of the extra provision stuff I have written into drush too, such as flexible logging and error handling, with the ability to run drush scripts and integrate the output of the commands (think update all sites on a platform, where every specific site's update command runs in it's own php process).

Committed this terrific work to HEAD. I moved a few commands into a new includes/core_commands.drush.inc. Below are some notes from my testing. We should investigate and patch these if possible.

Note that I did nothing with the D5 and D7 code that was posted. Lets deal with those branches once the dust settles.

I have not yet created the drush extras project to hold the remaining commands. I am thinking that I will do with a tiny .info and .module fie since many people will want to deploy the commands as modules so that the code is in a well known place for their whole dev team. agreed?

---------------

1. When passing --root, I have to pass an absolute path. If I use a path containing '~' such as ~/htd/pr6, I get a chdir error. Any idea why that is? Could we avoid that?

2. Lets give an error msg if file is not found in 'script' command ... Please add instructions about --root if 'No Drupal installation was found.' in status command ... The command declaration uses 'level' instead of 'scope'.

3. At some later date, we should get rid of globals like $GLOBALS['args'], $GLOBALS['override']

4. command.inc: We search for command files in all directories of all active modules. I think we should actually limit the searching to the 'commands' and 'includes' and root directories. I am worried that some modules ship with thousands of files and we will needlessly scan them all. Perhaps thats excessive caution?

5. With standalone drush, we list all available commands but you can't get Help on most of them unless you specify a site root. Seems incorrect to me. Lets fix that if not much special case code is needed.

6. We should merge the 'eval' and 'script' commands such that eval is an option on script (i think).

7. We really need to implement checking for 'scope' (i.e. site, system, ..). The core 'cron' command that I have added fails ugly when you don't specify a site.

8. I had a strange error when i defined the 'status' callback in both my home folder and in drush core. the error:
Warning: call_user_func_array(): First argument is expected to be a valid callback, 'core_commands_status::status_callback_status' was given in /Users/mw/contributions/modules/drush/includes/drush.inc on line 31. Ideally drush would just pick one command that is authoritative and use it.

It seems that modules can no longer provide drush command files because we fail the bootstapped condition in drush_commandfile_list(). Lets fix this fast. I am just finishing up drush_extras project but it will be not so useful until we fix this.

I have committed the pm, sql, tools commands into the new drush_extras project - see http://drupal.org/project/drush_extras. The committers for drush have commit access on Extras as well. I hope folks will subscribe to the issue queue there.

We need to work on the pm commands since we were expecting folks to only enable pm_cvs and pm_svn if they needed them but now they are always available from the perspective of help text. But their code is not available like it was with the module system? Perhaps Grugnog2 can look into this?

I think it would be useful if we got together on irc sometime to hash out some tickets for the way forward with drush.

That way we can at least plan which features need to be worked on, and get a general idea of the direction.

Everyone who matters has posted in this issue so I will announce here:

We will hold an IRC meeting about drush on Friday morning (USA). For your local time, see http://timeanddate.com/worldclock/meetingdetails.html?year=2008&month=12... .

Lets meet in #drupal-dev on freenode. If someone wants to create a dedicated room, we'll point each other there.

Lets discuss our visions and designs for the next generation of core and commands. Adrian will to share some of his code from the Aegir project.

Would be great if folks could port Drush Extras to HEAD. D5 is nice too, but less critical. See http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/drush_extras/

FYI, I took Vingborg's commands and branched drupal_extras for D6 and D5 in addition to HEAD. I made dev snapshot release nodes as well.

Reminder: the drush mtg begins in 30 minutes. See you in #drupal-dev on freenode

Houston - we have a problem (a good read - check it out).

I cannot get drush_extras to load in HEAD. The problem is that the whole module_list() situation has changed in HEAD. We now use a code registry to load stuff on demand. I am not at all sure we can cleanly keep our goal of a version agnostic drush.

I encourage everyone to take a look and see what can be done. The actual failure point is the call to module_rebuild_cache() in /includes/command.inc but thats a symptom of a greater problem.

Be sure to cvs up on drush_extras since I have just added some needed bits for it to be enabled on the Modules page.

I really should have caught this before we committed. Ugh.

i thought we decided not to look at modules for drush_command functions, so there would be only one way to define them?

We should not be using any drupal core functions in drush at all, and where we are forced to we can maintain a set of wrapper functions. When a new drupal release is required, only these will need to be updated.

I think changing 1 file (maybe) with something like 5 functions (conf_path, module_invoke, and some others) once per major Drupal release, is a lot cleaner and faster than changing X files with Y functions Z times (where z = number of patches committed , y and x are the files and functions changed in each patch).

I'll even offer to maintain that file for us with every release, as I will need to make provision compatible with the latest Drupal version, so it would be my first port of call.

I debugged this and found that nothing in the drupal api was changed enough for this not to work, and after some debugging i found the issue and wrote a patch.

The patch is here : http://drupal.org/node/349966

Making this fixed again (this should have been a different issue).

I debugged this and found that nothing in the drupal api was changed enough for this not to work, and after some debugging i found the issue and wrote a patch.

The patch is here : http://drupal.org/node/349966

Making this fixed again (this should have been a different issue).