Skip to content

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

Closed
wants to merge 4 commits into from

Conversation

javiereguiluz
Copy link
Member

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 -

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Sep 30, 2016

Just challenging this one: the pending doc PR on this topic now says:

You can also define the default value of any existing parameters using special environment variables named after their corresponding parameter prefixed with SYMFONY__ after replacing dots by double underscores (e.g. SYMFONY__KERNEL__CHARSET to set the default value of the kernel.charset parameter). These default values are resolved when compiling the service container and won't change at runtime once dumped.

See http://pr-6918-6qmocelev2lwe.eu.platform.sh/configuration/external_parameters.html#environment-variables

To me, the use case is different. env() parameters do not allow this (setting the default value of parameter at compile time through env vars).
Do we really consider this feature as something we don't want to support anymore?

@nicolas-grekas
Copy link
Member

If the answer is yes (see above challenge), shouldn't we deprecate EnvParametersResource and getEnvParameters also?

@linaori
Copy link
Contributor

linaori commented Sep 30, 2016

@nicolas-grekas if SYMFONY__ indicated that it was a value only used to build parameters and stores the calculated version, maybe something like build_env(...) could solve the problem?

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Sep 30, 2016

It's also a matter of who owns the relationship between the env and the config.
env() or any such alternatives are the way to go to pull from the env.
SYMFONY__ to push to parameter's defaults.
Different directions, different use cases to me.

@ro0NL
Copy link
Contributor

ro0NL commented Oct 1, 2016

It's also a matter of who owns the relationship between the env and the config.

Deprecating the magic SYMFONY__ vars brings back the ownership to the config.. imo that's a good thing.

@wouterj
Copy link
Member

wouterj commented Oct 1, 2016

If deprecation is coming, I don't agree with the implementation of the deprecation. I can imagine people want to keep the SYMFONY__ parameters and just instead request them with env('SYMFONY__') (to ease migration). This will currently still result in the deprecation...

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Nov 24, 2016

I propose #20618 as an alternative to using SYMFONY__ env vars for compile time env vars resolution. Which means I'm now 👍 to deprecate them, thus unlocking this PR on my side.

@nicolas-grekas nicolas-grekas added this to the 3.x milestone Dec 6, 2016
@@ -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);
Copy link
Member

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.

@nicolas-grekas
Copy link
Member

@wouterj can you think of another way? IMO, it looks sensible the way it is now.

fabpot added a commit that referenced this pull request Dec 17, 2016
…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);
Copy link
Member

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) {
Copy link
Member

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.

@nicolas-grekas
Copy link
Member

don't forget this one @javiereguiluz

@javiereguiluz
Copy link
Member Author

@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);
Copy link
Member

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".

Copy link
Contributor

@ro0NL ro0NL Jan 6, 2017

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@expectedDeprecation

@ro0NL
Copy link
Contributor

ro0NL commented Jan 6, 2017

If deprecation is coming, I don't agree with the implementation of the deprecation. I can imagine people want to keep the SYMFONY__ parameters and just instead request them with env('SYMFONY__') (to ease migration). This will currently still result in the deprecation...

This is true. Defining an SYMFONY__ env var is not deprecated, only the magic part where it's set as a parameter.

I also dont really agree on tests here.. using reflection smells.

I think roughly the path is

  • Remove $_SERVER implementation
  • Trigger deprecation if a SYMFONY__ var is defined, but not configured as a parameter, ie;
'database_name': '...'
  • Otherwise set the default value along with deprecation, ie;
'database_name': '%env(SYMFONY__DATABASE_NAME)%'

Should work out right?

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Jan 6, 2017

Let's be pragmatic here: if any SYMFONY__ env var exists, it's because we asked for them. Which means it's OK to deprecate the env vars. MHO.

@ro0NL
Copy link
Contributor

ro0NL commented Jan 6, 2017

👍 ok then. Already thought something like that.. just wanted to make sure we did not overlooked it :)

@chalasr
Copy link
Member

chalasr commented Jan 26, 2017

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 Kernel::getEnvParameters() method be deprecated?

@nicolas-grekas
Copy link
Member

rebase needed - to make tests green at least

@javiereguiluz
Copy link
Member Author

The rebase wen't wrong ... closing it in favor of #21889.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants