@malarzm Could it help for the following topics?
lexik/LexikTranslationBundle#420
#33358

Currently it seems complicated to resolve environment variable on loading extensions.

Currently it seems complicated to resolve environment variable on loading extensions.

No, this PR barely exposes accessing env variables to the outside world and does not change any parameters vs envs vs extensions.

@raziel057 not reading environment variables inside extensions is not a bug. It is afeature. The whole promise of env placeholders in the DependencyInjection is that new values of the environment variable will be taken into account without requiring to clear the cache. So if a container extension uses a setting to change the structure of the container instead of injecting into a service, it cannot use an env placeholder.

@stof Thanks for your answer. The issue is that often when you deploy an app in a container for example you don't want to embed a config file for static parameters that can change if you deploy the same image in different environment. It would be just nice / easier to be able to specify if the ENV should be resolved statically or not.

I have seen lots of people simply define static ENV vars in docker compose files or Kubernetes Management Platforms like Rancher for example.

I just seen this have been already discussed here:#40794

@raziel057 for such case, I'm still usinghttps://github.com/Incenteev/ParameterHandler to create non-env-based parameters duringcomposer install, based either on env variables or an interactive prompt.

I'm 👎 for the reasons given by@stof. Closing therefore, thanks for suggesting.

I'm sorry but I'm missing the reasons? To me it looks like discussion was unrelated to the proposal itself as it was about how envs are behaving.

would this already be achievable using either theParameterBagInterface orContainerBagInterface?

would this already be achievable using either the ParameterBagInterface or ContainerBagInterface?

It wouldn't expose processors that way as its logic is defined by\Symfony\Component\DependencyInjection\Container::getEnv itself. For instance in our example in our envs we have:SOME_FEATURE='2022-07-11 13:00:00'; and we have dedicated processor%env(feature_switch:SOME_FEATURE)% in services definitions (the processor treats date-ish strings asbool:'s true). Now if we'd be relying on stuff defined in parameters I would be forbidden to call%env(bool:SOME_FEATURE)% somewhere down the line (continuing my example, in a controller showing status of a feature) as that parameter does not exist (nor its fallback as we're defining it withfeature_switch:).

IMHO the way forward would be$this->parameterBag->get('env(csv:APP_FOO)')

which currently only works using a hack like

parameters:env(csv:APP_FOO):'%env(csv:APP_FOO)%'

making it work out-of-the-box would be more elegant though.

Rereading this again I'm 👎 here: exposing new APIs is increasing the maintenance cost, and here, ppl will jump into using the method and shooting themself in the foot (see comments from@raziel057 and@stof)

IMHO the way forward would be $this->parameterBag->get('env(csv:APP_FOO)')

Yes, that's a good way forward (it works with any parameter name, not onlyenv(...))`

Closing as explained, thanks for proposing.