Currently, drush is searching for drushrc files in a number of places, but it breaks as soon as it finds one. That makes it hard to maintain site-wide or system-wide settings.

I propose that the break is removed. A few quick experiments have me satisfied that it works on my machine with no obvious side-effects.

I'll post a patch in a short while, but I'll appreciate any thoughts on the issue, especially regarding a sensible search-order for drushrc files.

Comments

moshe weitzman’s picture

moshe weitzman commented

Since I only ever used one file at the site root, I never ran into a problem. Anyone have an opinion on this?

owen barton’s picture

owen barton commented

For some reason that is the way I always figured it worked anyway, I just never actually had cause to test it out! +1 for removing the break.

adrian’s picture

adrian commented

can't you just include your system level settings from your site wide settings ?

vingborg’s picture

vingborg commented

adrian, I'm not sure I understand you correctly. The effect I want to achieve is that I can set 'handler', for instance, to 'wget' in the .drushrc in my home directory, so that I won't have to set it in any other drushrc file, except if I have good reasons to. My case is, that I usually have several distinct Drupal installations checked out and I want to share as many drush options across them as possible. In many cases I would be able to avoid having a per-installation drushrc at all, so I could just check out my project and start working it with drush.

My intentions for this is closely related to #335360: Drush does NOT have to be a module!, especially regarding your own --include suggestion.

adrian’s picture

adrian commented

I've recently started thinking about this, and it could be useful.

It wouldn't be a big patch either, and would be especially useful to my purposes. I already do something similar to be honest, and this would drastically reduce the amount of custom code for this stuff.

So you would be able to configure it on 'server wide' level (where i would store settings such as how to restart apache), then on the platform level (ie: a drupal checkout on the server, where i would store settings specific to all sites on that release / platform) and then the site specific level (ie: $root/sites/$url).

This is going to be especially useful for a version agnostic drush.

vingborg’s picture

vingborg commented

@adrian: yep. I've actually included it in my next revision of the agnostic drush. It's a small patch, all right, and could easily be backported, if that would be interesting for anyone.

In the version mentioned, the configfile loader ends with the drushrc.php file in the drush installation directory, but that really should be a proper, system wide location. How would one go about locating that in a properly cross-platform manner (i.e. to cater for the Windows audience)?

adrian’s picture

adrian commented

I would do it the other way around.

drush install dir, overridden by drupal root, overridden by sites/$url/drushrc.php, [overridden by ~/drushrc.php?], overridden by command line arguments.

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Fixed

I think this is in. If I am wrong, please reopen.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.