Document setting Drush config values via environment variable

[weitzman]

The logic for the default value for this config is in drush_find_tmp(). Not changing any logic here, using config system.

[greg-1-anderson]

The standard is for a .env file with environment variables. Maybe we should support that in consolidation/config?

[weitzman]

I have used .env files on a couple project and find them very convenient. Sounds great.

I think this change in Drush could happen in parallel with a consolidation/config change, right?

[greg-1-anderson]

For new designs it is often preferable to implement in Drush first, and then refactor / extract to external components. In cases like this where the new behavior is already incremental to functionality that has already been extracted, I'd say that it is best & just as easy to implement directly in consolidation/config first.

[greg-1-anderson]

We need a way to map from a config element to an environment variable. Maybe convert . to _ and then uppercase and prepend DRUSH_. That's a start. With that rule, drush.alias-path would become DRUSH_DRUSH_ALIAS-PATH.

The two obvious flaws with this proposal:

• DRUSH_DRUSH is sub-optimal, but not all config items start with drush., and all environment variables should.
• Having a - instead of a _ is inconsistent; however, if we converted it to DRUSH_DRUSH_ALIAS_PATH, I'm not sure how we would know whether to convert that back to drush.alias-path instead of drush.alias.path.

Terminus searches both $_SERVER and $_ENV for matches, and overrides set to convert the key to a constant if applicable. Config is read via DotEnvConfig. There is a yml file listing all valid key constants.

Terminus has neither hierarchy nor -s in their config symbols; they would just use alias_path instead of drush.alias-path. Not sure I'd be happy to do likewise.

Maybe rather than reading all of the env variables and applying them as a config, we could instead change the implementation of default handling to check the environment variable before returning the default value. Then the lossy transformation to DRUSH_DRUSH_ALIAS_PATH would be okay, as we would never need to go the other way.

[weitzman]

My original idea for this issue is now a PR at #3137

However, lets discuss the Env variable mapping. It looks like consolidation/config now supports setting config from Env variables. We need to document how that works, or point to docs in consolidation/config. @greg-1-anderson any chance you could write a couple examples here. I can turn them into docs on examples/example.drush.yml

To answer the questions above

1. I'm not overly bothered by the DRUSH_DRUSH_ naming. Seems hard to avoid.
2. Its nearly impossible to set an environment variable with dashes in the name on the CLI. See https://stackoverflow.com/questions/35151619/source-a-file-containing-environment-variables-including-dash-character-in-bas

[greg-1-anderson]

consolidation/config maps both . and - to _ in the environment variable name, so dashes in the environment name are not a problem (won't happen).

[legovaer]

My 5 cents: I created a PR which allows you to use environment variables in your alias (yaml) file same way as Symfony does it. Have a look at #3202

[weitzman]

yaml-expander got the nice env feature we hoped for. docs still needed.