ocean waves
DDEV logo

Using `drush use` with DDEV

I've been using DDEV a lot lately. In fact, Redfin went 100% all in on DDEV for local development a few months back. I can finally grok Docker and how it works, and though we've also switched to per-project configs, which adds some complexity, it more matches the reality of what we're used to dealing with.

There was, however, one thing that had me stumped recently.

Drush Use

We use a Drupal multisite installation for a lot of the sites we host at Redfin, and we are often working on just one of them at a time. Enter drush site:set, or as I refer to it (by its alias), drush use.

This lets you assume a particular site alias for future Drush commands for the duration of your "session" (that is, a Bash or other shell session). This is easier than having to use the alias or the --uri parameter to each Drush call. That is, instead of:

drush @mybiglongsitealias.local cr or drush --uri=mybiglongsite.com cr every time,

we can just do:

drush use @mybiglongsitealias.local then drush cr

The trick is - how long does this last? Well, in Drush land this is for the duration of your Bash session. With DDEV, however, every ddev drush <cmd> is its own session, so the use is... well, useless!

Fixing This

To fix this, I had to root around in the drush code a bit, but as it turns out the drush command puts the alias in a temporary file, like /tmp/drush-use-####, where #### is the process ID (PID) of the currently running Bash shell. As it turns out, though, you can override the automatic detection of the PID by setting it as an environment variable. For me, I set the environment variable to "PERMANENT" in my .ddev/config.yaml.


Conveniently, DDEV lets you set environment variables easily.

Now, the file ends up as something like /tmp/drush-use-PERMANENT and each time you dip into your shell it uses the same file. Though this goes against the letter of the idea of "this session," it's useful in a DDEV context so you can use ddev drush commands from outside the container. (Inside the container, this works fine because it's all the same Bash session when you do ddev ssh.) What the session actually becomes then is "this ddev session," which is wiped out of if you do a ddev stop (or poweroff, etc), so I don't think it violates the spirit of the Drush maintainers' idea of "this session."

Happy DDEVing!