I surely miss something but#20100 (comment):

shouldn't the Kernel::getEnvParameters() method be deprecated?

Or do we plan to trigger this deprecation forever?

Vastly prefer the implementation described in#20100 (comment). I was going to comment on this earlier, but couldn't find that comment by@chalasr.

@chalasr about your comment, I don't agree on reporting the deprecation when using the env var instead of when setting it (if you set it, it's because you have defined it ... so you should get the deprecation).

About the other proposal ... I don't know what to say ... but others think it's much better, so if you can implement it, I guess we can close this PR in favor of your PR. Thanks!

The reason I believe we shouldn't getany deprecations until an environment variable isactually used is because otherwise, we are restricting the use ofexternal environment variables without knowing that they are intended for consumption by Symfony itself. People may well be using environment variables beginning withSYMFONY__ for their own container port mapping or other functionality related to setting up their Symfony environment, but external to the Symfony runtime itself.

@javiereguiluz My point is mainly what@robfrawley said in the previous comment, but also that deprecatingSYMFONY__ prefixed env vars does not make sense to me in term of upgrade.
Defining these prefixed env vars will not stop to work, only using them as parameters will.
The symfony-specific behavior is only to consider these vars differently, I think the deprecation should reflect this and that this behavior should really die in 4.0 (i.e.Kernel::getEnvParameters() be removed).
I'll propose the alternative PR.

@chalasr yes, I agree that both of you are right and your solution is better than mine :) Thanks for providing the alternative PR. I'll close this one then.

In think this implem here is right, but misses the deprecation ofKernel::getEnvParameters
The false positive that has been identified makes no harm at all: it's mainly theoretical, and it's not like it's going to break anything (4.0 won't throw - it'll just ignore and not warn anymore).

The alternative proposed in#21997 looks worse to me because it breaks SRP.

Until someone finds another solution freed from any of the identified drawbacks, I'm 👍 here (I won't be the one working on this as the identified drawback of this PR doesn't look that realistic to me.)

For the record, I still think that comments from Rob and Robin are right ... but I'll update this PR in case we don't find a viable alternative solution.

Reopening, this looks like the correct approach to me:

Defining these prefixed env vars will not stop to work, only using them as parameters will.

SYMFONY__ is not a common prefix. I'd better consider that we can claim triggering a deprecation notice here. In terms of DX, it's also way more important to me to warn users that if they expect aSYMFONY__ env var to be taken into account, then that won't happen in 4.0, even in the case they don't actually use it as params.

even in the case they don't actually use it as params.

If not used as a parameter then there is no reason to expect the env var to be taken into account. I don't understand how this is a better approach regarding DX, but let's move on.

@chalasr since these env vars are used asdefault values, they can very well be defined by the env just in case - but actually not being used because the param is defined / not used by the current app.

missing entries in CHANGELOG / UPGRADE files

👍

Tests are broken.

The last failing tests seem unrelated, so this is now ready! A big "thank you" to@chalasr for his great help fixing all the failing tests.

Thank you@javiereguiluz.