Environment variables and semantic configuration

[derrabus]

I think the documentation should be a bit clearer on the limitation of %env(…)% placeholders inside a bundle's semantic configuration.

• Reading the section "Configuration Based on Environment Variables", an app developer could get the impression that they could simply replace arbitrary pieces of the bundle configuration with env variables (see [DotEnv] Cannot pass .env parameters in bundles config symfony#39625).

• The guide "How to Create Friendly Configuration for a Bundle" should explain how to deal with env placeholders and how to not break the laziness of env variables at compile time.

[fabpot]

I think we should also emphasize that not everything is a good candidate for an env var. In fact, we should be very clear that most of the time, you must not use an env var for anything that does not need to change dynamically in production without a clear cache.

I see too many developers trying to fit their configuration in env vars, which is very wrong (slower for no benefits).

[much-rebel]

@derrabus thanks for taking a look at it, the proposed amendments for the documentation would be very appreciated indeed.

Currently I couldn't find any documentation on how env vars should be introduced to my own bundles.

Adding $container->resolveEnvPlaceholders(...) in Extension class doesn't work with type casting. Adding ResolveEnvPlaceholdersPass in the Bundle::build as an error message suggest, doesn't work either as the passes would be resolved after bundle's configurator tries to access parameters, which is too late.

So I'm bit lost, documentation says use DotEnv, then says even type casting is available, but nowhere is mentioned that bundles would not support any of that out of the box, using them would slow application, etc.

Currently at our team we do have a project which runs same code base at separate servers with different locales, country settings, utilises some piece of code in independent bundles, so placing those settings in DotEnv seems to me as a potentially a good use case. However currently I'm stuck with old style use of parameters.yml loaded in services.yml and ignored in git :/ which makes whole use of DotEnv kinda useless, except hashed secrets and other sensitive info which would be exposed in yamls.

[fabpot]

@much-rebel To me, this is a wrong usage of env vars. You won't change the locale of a server dynamically, so you should configure your locale in a parameters.yml-style file. It's not old style. Env vars do NOT replace parameters, they fix a very narrow problem which you don't have AFAICS.

[much-rebel]

@fabpot okay, got it, thank you. Could you give a real life example of DotEnv usage so I would understand a concept of it better? Except secrets...

[javiereguiluz]

@much-rebel in symfony.com website, we store the Slack invite URL in an env var so we can update it when it expires without having to deploy the entire website.

[noniagriconomie]

@much-rebel there is this https://speakerdeck.com/nicolasgrekas/configuring-symfony-from-localhost-to-high-availability
values defined in config file or as constants or env variables

[carsonbot]

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

[carsonbot]

Hello? This issue is about to be closed if nobody replies.

[derrabus]

still relevant

[carsonbot]

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

[derrabus]

No, it hasn't.