-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Deprecate the special SYMFONY__ environment variables #20100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
javiereguiluz
commented
Sep 30, 2016
Q | A |
---|---|
Branch? | master |
Bug fix? | no |
New feature? | no |
BC breaks? | no |
Deprecations? | yes |
Tests pass? | yes |
Fixed tickets | #20089 |
License | MIT |
Doc PR | - |
Just challenging this one: the pending doc PR on this topic now says:
To me, the use case is different. |
If the answer is yes (see above challenge), shouldn't we deprecate |
@nicolas-grekas if |
It's also a matter of who owns the relationship between the env and the config. |
Deprecating the magic |
If deprecation is coming, I don't agree with the implementation of the deprecation. I can imagine people want to keep the |
I propose #20618 as an alternative to using |
@@ -537,6 +537,7 @@ protected function getEnvParameters() | |||
$parameters = array(); | |||
foreach ($_SERVER as $key => $value) { | |||
if (0 === strpos($key, 'SYMFONY__')) { | |||
@trigger_error('SYMFONY__ special environment variables are deprecated as of 3.2 and will be removed in 4.0. Use instead the %env()% syntax to get the value of environment variables in configuration files.', E_USER_DEPRECATED); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, we should either add the full $key in the message, or move the deprecation outside of the loop.
@wouterj can you think of another way? IMO, it looks sensible the way it is now. |
…ble to inline the values of referenced env vars. (nicolas-grekas) This PR was merged into the 3.3-dev branch. Discussion ---------- [DI] Make ContainerBuilder::resolveEnvPlaceholders() able to inline the values of referenced env vars. | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Being able to resolve environment variables at compile time as a replacement for `SYMFONY__` special env vars, unlocking their deprecation (see #20100). Commits ------- 713b081 [DI] Make ContainerBuilder::resolveEnvPlaceholders() able to inline the values of referenced env vars.
@@ -537,6 +537,7 @@ protected function getEnvParameters() | |||
$parameters = array(); | |||
foreach ($_SERVER as $key => $value) { | |||
if (0 === strpos($key, 'SYMFONY__')) { | |||
@trigger_error(sprintf('The special environment variables that start with SYMFONY__ (such as "%s") are deprecated as of 3.2 and will be removed in 4.0. Use instead the %env()% syntax to get the value of environment variables in configuration files.', $key), E_USER_DEPRECATED); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3.3
$deprecationMessage = 'SYMFONY__ special environment variables are deprecated as of 3.2 and will be removed in 4.0. Use instead the %env()% syntax to get the value of environment variables in configuration files.'; | ||
$expectedDeprecations = array($deprecationMessage, $deprecationMessage); | ||
|
||
ErrorAssert::assertDeprecationsAreTriggered($expectedDeprecations, function () use ($kernel, $method) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You now have to use the annotation instead.
don't forget this one @javiereguiluz |
@nicolas-grekas updated with the fixes suggested by reviewers. |
@@ -537,6 +537,7 @@ protected function getEnvParameters() | |||
$parameters = array(); | |||
foreach ($_SERVER as $key => $value) { | |||
if (0 === strpos($key, 'SYMFONY__')) { | |||
@trigger_error(sprintf('The special environment variables that start with SYMFONY__ (such as "%s") are deprecated as of 3.3 and will be removed in 4.0. Use instead the %env()% syntax to get the value of environment variables in configuration files.', $key), E_USER_DEPRECATED); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would move "instead" after "syntax".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and will be removed in 4.0
We cant really remove user env vars ^^ i'd go with and are not supported anymore in 4.0
.
@@ -719,6 +719,22 @@ public function testTerminateDelegatesTerminationOnlyForTerminableInterface() | |||
} | |||
|
|||
/** | |||
* @group legacy | |||
* @expectedExceptionMessage The special environment variables that start with SYMFONY__ (such as "SYMFONY__FOO__BAR") are deprecated as of 3.3 and will be removed in 4.0. Use instead the %env()% syntax to get the value of environment variables in configuration files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@expectedDeprecation
This is true. Defining an I also dont really agree on tests here.. using reflection smells. I think roughly the path is
'database_name': '...'
'database_name': '%env(SYMFONY__DATABASE_NAME)%' Should work out right? |
Let's be pragmatic here: if any |
👍 ok then. Already thought something like that.. just wanted to make sure we did not overlooked it :) |
Instead of triggering the deprecation when registering the parameter, couldn't we trigger it when getting the parameter (reversing the key transformation and trigger if we find it in $_SERVER)? Also, shouldn't the |
rebase needed - to make tests green at least |
The rebase wen't wrong ... closing it in favor of #21889. |