Aliases cannot use parameters at all (since Symfony 2.0.0), be there env variables or no.

And btw, supporting env variables there is a no-go IMO. The whole point of env variables is that they are resolved at runtime. And aliases are validated and resolved at compile time. Adding a dynamic target for an alias would require rewriting all code dealing with aliases (and adding overhead for all aliases in the container, to check at runtime whether they need to be resolved dynamically...)

I suggest opening an issue on swiftmailer bundle instead, this is where the issue exists: too many logic done at compile time

@nicolas-grekas this issue comes from MonologBundle. And processing the whole bundle config at runtime to decide which handlers to create and how looks insane to me. I don't think the overhead it will add is justified, compared to being able to switch the logger handlers at runtime without a deployment (thus, most of them expect different configuration settings, and potentially different dependencies, so it would simply not work).

indeed :)

btw, the same is true for the swiftmailer transport: each transport expect different config settings

Well there is still option B and C available :)

B. Introduce a compile time env variable support as well so we can also be allowed to inject variables at compile time without having to resolve to custom env.php kind of solutions.

Why not use SYMFONY__* env vars instead of env.php? see also #20100 (thus if you think this should not be deprecated, please comment there)

Why not use SYMFONY__* env vars

They are rather pointless, they are overridden by defined parameters making them useless for the case at hand (yml having defaults, env being able to override), hence support use with and without.

instead of env.php

I did get rid of env.php approach, but what I ended up with for now is to use comoser.json incenteev-parameter.env-map for compile time params, and env() for run time options. But with all the recent env improvements I was hoping to avoid having to use incenteev/composer-parameter-handler, I was kind of expecting some standard convention could solve this now ;)

OK. You can also do that in your bundle extension: resolve env vars and inject them in params. That'd be 100% compile time.

true, but if symfony came with something like %compile_env()% then I would not have to hard code that in the bundle, it can be user defined in the yml files we provide to end user.

I'd be in favor of closing this one, and replacing it with a doc issue. IMHO, we should not provide helpers to make people use env vars at compile time. Doing so means making the container not runtime-configurable for the corresponding envs. While there are legitimate use cases to do so, there are already ways to do that (the simplest one being to getenv() in a compiler pass, the more advanced being to use ContainerBuilder::resolveEnvPlaceholders()).

ok

is there a way to shut down the %env()% trick? honestly i ran into so many issues with it that i just use a parameters.php to do set my parameters, wasted a lot of time because of this.

@cordoval it's not really a trick but a feature :) And there's no direct way to disable it ... but there's an indirect way: not using it in any config file.

thanks @javiereguiluz i know the features are with good intentions, just so frustrating 👴 uff uff