Allow configuring the environment via an environment variable

So E.g. you could set this in a test like: putenv('DRUPAL_ENV=test') too.

That doesn't work for actual webtests ... there I guess we want to use prod anyway?

Added a couple of examples that environment variables are a common thing.

I kinda like the idea :).

I just love the patch, still!

+1 for PHPDotEnv

Updating issue summary. I'm not clear if this counts as a Drupal API change, but it's a far-reaching DX change that should be documented.

Where is the appropriate place to document it in core itself?

I did say I wasn't clear whether to call this an API change. I sought clarification, because I'm not sure what to call it really - configuration, policy, ...? Before this patch, there wasn't an official way to tell the kernel about the environment, now there is.

It's far-reaching precisely because any developer can respond to it in any way they please. They can already use any arbitrary environment variables, of course, but this standardizes one which "belongs" to Drupal. If a sys-admin is to consider setting it, they need to know what it's supposed to be for.

My point is: if it has a big official-sounding "DRUPAL_" at the start then it's purpose and/or usage-guidelines should be documented somewhere. I'd expect to be able to find it on api.drupal.org for instance. If it doesn't have a clear purpose, then we're introducing something that can be used and abused arbitrarily.

I'm playing the fool, but this doesn't sound like a trivial addition to me.

Reworded the API section. How does "facilitates use of an environment variable" sound?

Yes, going by the patch in #1, it ought to be documented in DrupalKernel.

It should probably be documented somewhere else too, though. If it's an official Drupal environment variable, then a developer can react to it directly with getenv(), regardless of what the kernel does with it.

Perhaps in INSTALL.txt, or whichever handbook pages deal with server set-up. Maybe some examples of how to use it.

#19: I personally would still like to see this change.

What about adding an official API to DrupalKernel to get the running version:

e.g.

\Drupal::service('kernel')->getEnvironment()

or something like this?

Then anyone could do so as they please, but it would work the same with exchanged front-controller and with environment.

A getenv('DRUPAL_ENV') would then be a non-recommended API mis-use as it could not match and there is an official way, which means this is mainly important for sysadmins / devops then.

Well, IMHO we should pass that as container parameter and this is all.

Oh indeed, there is kernel.environment

I added a general plan issue for environment variables: #2879846: Provide better support for environment variables

Adding Symfony's dotenv component to the Issues Summary as another possible option.

Since Drupal is already heavily using Symfony I believe it makes more sense to stick with Symfony, but left the phpdotevn library there as an alternative option.

Presumably lots of folks already use dotenv (symfony or otherwise) w/ Drupal; I know I do. Adopting it "officially" seems like a great idea.

That seems absolutely sensible. Having a big of a bigger plan for environment variables #2879846: Provide better support for environment variables would probably be nice for framework maintainers to make a comment about it.

In order to support the environment-specific config, #3028179: Config Environment module (original issue) wants to store the environment within the Drupal State system and will add a service for switching between environments (causing the appropriate config changes via ConfigTransform #2991683: Move configuration transformation API in \Drupal\Core\Config namespace).

While people are still fleshing this out, there will be some way to set the environment from the command line (e.g. drush) or via a service method. This is more complicated than just "change this variable in settings.php" as it requires updating the active config.

The new service should support "getEnvironment" and "setEnvironment" methods to hide the implementation details of using the State variable and rather than querying kernel.environment directly. The fact that Kernel already has an "environment" makes this more complex as that is used for container caching and might not be the same as the "config environment".

Since there is another issue for discussing support for environment variables more generally, perhaps this discussion can focus on the proper service API for getting/setting the environment to be compatible with the needs of Kernel and for environment-specific config.

I'd suggest that we have a few different environments for use by core dev and CI: 'prod', 'update', 'functionaltest', 'kerneltest'.

This would allow us to factor all the brittle edge cases out of the kernel itself, and swap out CoreServiceProvider for FunctionalTestCoreServiceProvider and so forth.

In this way, the kernel could get rid of having to ask about DRUPAL_TEST_IN_CHILD_SITE and just act as if it's a site under test because we told it explicitly.

This would mean we don't allow the kernel to be configured by an environment variable because it should be configured by the caller. index.php would say 'prod', update.php would say 'update', and so forth.

Hmm, I would have thought that update could be running in prod, dev or test environment but wouldn't itself be an environment.

Maybe we should question this practice first. For example the twelve-factor app methodology is advising against grouping like stage, production, etc. See: https://www.12factor.net/config

I personally am not proposing configuration grouping, I just wanted a way to identify which environment the app is running in (prod/dev/test). Some internal logic could use the environment parameter, while typical configs that need to be set for each instance/deploy would still use environment variables.

This is a massive, potentially fatal error introducing change. I think the time is now or never -- if we announced it six months ahead that D9 will ship like this then people running containers (because that's where you'll use this mostly) can verify they don't have anything named DRUPAL_ENV. But that's just my opinion, I do not feel ... specified ... to set this to 9.x-dev.

I think kernel has to handle environments first (see #36) in existing callers, and then we can try to introduce DRUPAL_ENV to actually handle them.

Meanwhile filled issue for the 'update' environment #3126222: Introduce 'update' environment for DrupalKernel

In my recent blogpost (Web Archive Link) I've outlined how this comes essentially for free with #3313404: Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments while providing end-users an easy way to swap out the logic if needed.

[The Symfony Runtime Component usage] provides us with a standardised way to get the environment name regardless of what kind of application you're building. For the initial Runtime implementation we may even resolve the $environment variable statically to prod to mimic the current behavior. That would allow work to be done in [this issue] to determine the name of the variable that sets the environment and then provide this as an update to Drupal websites without having to touch their front-controllers again. Alternatively if they're unhappy with how Drupal determines the environment, then they can overwrite the runtime to resolve this variable themselves, without having to touch the front-controller.