Retrieve values for env var from $_ENV in addition to $_SERVER.

It seems you are conflating $_ENV in the title and getenv() in the merge request, but these are actually two distinct mechanisms.

In any case, I'm hesitant to make such a change for a few reasons.

For one, it's a good idea to use one of the PHP packages dedicated to managing environment variables - either symfony/dotenv or vlucas/phpdotenv. These packages can read your environment variables from a file and make them available via $_SERVER, where they would also appear if you were using "real" environment variables (the "recommended" PHP configs actually leave $_ENV empty as a performance micro-optimization).

In certain environments where multiple PHP requests (perhaps from different apps entirely) share the same process, e.g. because of usage of threads, it's not safe to call putenv()/getenv() because the environment variable will be set/retrieved for the entire process, not just the request in question. By default, symfony/dotenv and vlucas/phpdotenv don't use putenv() or getenv(). So, it's generally not a good idea to encourage use of these functions.

The logic to look for environment variables only in $_SERVER actually comes from upstream, in the Sentry PHP SDK. So, it seems I'm not alone in my opinions on this.

So my preference would be that if you're running in to this issue, rather than make a change in this module, you should either use one of the dotenv packages or, if using custom code, set these environment variables via $_SERVER so it's compatible with this module.

But if there's any reason that one of these alternatives would be difficult, I'd like to hear about it.

Thanks fr for the clarification with $_ENV and getenv().

My purpose is not to replace the logic with $_SERVER but to also use $_ENV if needed.

The default configuration for PHP for variable order is EGPCS.
You could have the same issue if you run an application with an empty string for that configuration.

Have a value in $_SERVER or $_ENV is the same if you have multiple application running on a same process.
In this case I'm not sure the issue is where the env var are set but that you have different app that runs on the same process and could access to those values.

Sure I could use another module in order to add all my env variable to $_SERVER but I think it's dumb to add a complete module for 3 variables.

My need is that I run my apps with docker. All my per environment configuration are managed thru .env passed to docker.
Unfortunately, when I use this configuration env vars are not included in $_SERVER but in $_ENV.

I change my code to use $_ENV instead of getenv. I also mutualise those settings in one static class.

Are you using symfony/dotenv or vlucas/phpdotenv to setup your environment variables? My understanding of both of those packages is that they should populate $_SERVER.

If you're using some other code to deal with environment variables, what is that code? Can you configure/change it to populate $_SERVER, at least for these variables?

This module is basically just a wrapper around the Sentry PHP SDK for easier integration with Drupal. If you weren't using this module, you'd have the same issue with the SDK only checking $_SERVER for environment variables, so I'd prefer not to have a lot of extra code for an edge case where environment variables can't be found there.

I agree, I could add some code to provide value from $_ENV to $_SERVER.

For all other env var I need I use them in custom module and use $_ENV.

I complete the PR with test. Don't want to keep a non working branch even if you trash it.

@nguerinet not trying to "trash" your merge request, but trying to figure out if there's a need for this extra logic in the module, or if you could resolve by using one of the dotenv libraries and/or tweaking your custom code. If it *is* needed, then arguably it would also be needed upstream in the Sentry SDK.