SYMFONY__ Env Variables overwriten by parameters.yml #7555

Closed
beberlei opened this Issue Apr 3, 2013 · 34 comments

Comments

Projects
None yet
@beberlei
Contributor

beberlei commented Apr 3, 2013

I want to use the SYMFONY__* env variables that are detected in Kernel are overwritten by parameters of the same name in parameters.yml for example.

However i would suppose using the environment variables is a mechanism to overwrite the parameters.yml in production, so exactly the other way around.

Is the current behavior there for a reason? It doesn't make much sense to me.

@beberlei

This comment has been minimized.

Show comment
Hide comment
@beberlei

beberlei Apr 3, 2013

Contributor

I am fixing this now by doing:

public function registerContainerConfiguration(LoaderInterface $loader)
{
    $loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml');

    $envParameters = $this->getEnvParameters();
    $loader->load(function($container) use($envParameters) {
        $container->getParameterBag()->add($envParameters);
    });
}
Contributor

beberlei commented Apr 3, 2013

I am fixing this now by doing:

public function registerContainerConfiguration(LoaderInterface $loader)
{
    $loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml');

    $envParameters = $this->getEnvParameters();
    $loader->load(function($container) use($envParameters) {
        $container->getParameterBag()->add($envParameters);
    });
}
@gionn

This comment has been minimized.

Show comment
Hide comment
@gionn

gionn Dec 3, 2013

+1 as now environment variables are unusable.

gionn commented Dec 3, 2013

+1 as now environment variables are unusable.

@icio

This comment has been minimized.

Show comment
Hide comment
@icio

icio Dec 5, 2013

+1 This was also the behaviour that I expected with http://12factor.net/config in mind

icio commented Dec 5, 2013

+1 This was also the behaviour that I expected with http://12factor.net/config in mind

@icio icio referenced this issue in Incenteev/ParameterHandler Dec 6, 2013

Closed

Override parameter.yml.dist values from Environment Variables #42

@icio

This comment has been minimized.

Show comment
Hide comment
@icio

icio Dec 6, 2013

Note that Incenteev/ParameterHandler has built-in support for setting parameters based on environment variables when running composer install.

icio commented Dec 6, 2013

Note that Incenteev/ParameterHandler has built-in support for setting parameters based on environment variables when running composer install.

@lavoiesl

This comment has been minimized.

Show comment
Hide comment
@lavoiesl

lavoiesl Jan 24, 2014

Contributor

Setting parameters using environment variables in parameters.yml is great, but it is only considered if the variable is not yet populated and will not change if the environment variable changes.

What was initially proposed is a good idea, but would it be nice to have built-in support for arbitrary environment variables ? That way, when composer install asks for the database host, you can write something like ENV:MYSQL_HOST. The parameter handler could also be changed to use this behaviour as default.

Contributor

lavoiesl commented Jan 24, 2014

Setting parameters using environment variables in parameters.yml is great, but it is only considered if the variable is not yet populated and will not change if the environment variable changes.

What was initially proposed is a good idea, but would it be nice to have built-in support for arbitrary environment variables ? That way, when composer install asks for the database host, you can write something like ENV:MYSQL_HOST. The parameter handler could also be changed to use this behaviour as default.

@mvrhov

This comment has been minimized.

Show comment
Hide comment
@mvrhov

mvrhov Jan 24, 2014

Contributor

@lavoiesl: That's the problem with the whole dic compilation thing. It doesn't support dynamic config settings.
Even with the introduction of the Expression engine in 2.4 you can't really have the dynamic config settings written into the app/confix*

Contributor

mvrhov commented Jan 24, 2014

@lavoiesl: That's the problem with the whole dic compilation thing. It doesn't support dynamic config settings.
Even with the introduction of the Expression engine in 2.4 you can't really have the dynamic config settings written into the app/confix*

@lavoiesl

This comment has been minimized.

Show comment
Hide comment
@lavoiesl

lavoiesl Jan 24, 2014

Contributor

I thought more about my suggestion and it would be impractical to parse all the values, there is ~300 parameters and some of them are arrays. However, one could add an environment_map parameter and do something like this:

<?php
$loader->load(function($container) {
    $bag = $container->getParameterBag();

    foreach ($bag->get('environment_map') as $parameter => $var) {
        $value = getenv($var);
        if ($value !== false) {
            $bag->set($parameter, $value);
        }
    }
});

Perhaps this should be in a CompilerPass

This would be robust, flexible and performant.

Contributor

lavoiesl commented Jan 24, 2014

I thought more about my suggestion and it would be impractical to parse all the values, there is ~300 parameters and some of them are arrays. However, one could add an environment_map parameter and do something like this:

<?php
$loader->load(function($container) {
    $bag = $container->getParameterBag();

    foreach ($bag->get('environment_map') as $parameter => $var) {
        $value = getenv($var);
        if ($value !== false) {
            $bag->set($parameter, $value);
        }
    }
});

Perhaps this should be in a CompilerPass

This would be robust, flexible and performant.

@stof

This comment has been minimized.

Show comment
Hide comment
@stof

stof Jan 24, 2014

Member

@lavoiesl The issue is that this would still not change the parameters once the container is compiled and cache

Member

stof commented Jan 24, 2014

@lavoiesl The issue is that this would still not change the parameters once the container is compiled and cache

@lavoiesl

This comment has been minimized.

Show comment
Hide comment
@lavoiesl

lavoiesl Jan 24, 2014

Contributor

Couldn’t this logic be added in initializeContainer, before the cache warmer ?

Contributor

lavoiesl commented Jan 24, 2014

Couldn’t this logic be added in initializeContainer, before the cache warmer ?

@stof

This comment has been minimized.

Show comment
Hide comment
@stof

stof Jan 24, 2014

Member

@lavoiesl this would still be the same: initializeContainer is about building the container. Once your container is cached, it will not be called anymore until the cache is cleared.

Thus, allowing to change parameters in a cached container would forbid doing any of the optimizations of parameters done currently: parameter values (which can depend on other parameters) are resolved at compile time (the FrozenParameterBag does not resolve them anymore) and the arguments using a parameter are getting the value inlined.
Frocing to resolve the parameter values at runtime rather than compile time will impact performances

Member

stof commented Jan 24, 2014

@lavoiesl this would still be the same: initializeContainer is about building the container. Once your container is cached, it will not be called anymore until the cache is cleared.

Thus, allowing to change parameters in a cached container would forbid doing any of the optimizations of parameters done currently: parameter values (which can depend on other parameters) are resolved at compile time (the FrozenParameterBag does not resolve them anymore) and the arguments using a parameter are getting the value inlined.
Frocing to resolve the parameter values at runtime rather than compile time will impact performances

@lavoiesl

This comment has been minimized.

Show comment
Hide comment
@lavoiesl

lavoiesl Jan 25, 2014

Contributor

@stof correct me if I'm wrong, but I was under the impression that it was, in fact, always executed. The container is first rebuilt if needed, but then, at https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Kernel.php#L568 some other code could be inserted.

Contributor

lavoiesl commented Jan 25, 2014

@stof correct me if I'm wrong, but I was under the impression that it was, in fact, always executed. The container is first rebuilt if needed, but then, at https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Kernel.php#L568 some other code could be inserted.

@lavoiesl

This comment has been minimized.

Show comment
Hide comment
@lavoiesl

lavoiesl Jan 25, 2014

Contributor

Oh, sorry, I misread your point about dependent parameters. See my PR for a possible solution.

Contributor

lavoiesl commented Jan 25, 2014

Oh, sorry, I misread your point about dependent parameters. See my PR for a possible solution.

@simensen

This comment has been minimized.

Show comment
Hide comment
@simensen

simensen Dec 1, 2014

Contributor

This is not at all what I expected, either. It was my expectation that you could set and override parameters from environment variables.

What if there was a service that could be added to the container that could look to see which params were set by the env and whether the env values are different? At least in development, we could get a warning (or error) in this case. Maybe this service would only run in dev/test? Minimal performance impact in dev/test env but still allow for flexibility for overriding?

Contributor

simensen commented Dec 1, 2014

This is not at all what I expected, either. It was my expectation that you could set and override parameters from environment variables.

What if there was a service that could be added to the container that could look to see which params were set by the env and whether the env values are different? At least in development, we could get a warning (or error) in this case. Maybe this service would only run in dev/test? Minimal performance impact in dev/test env but still allow for flexibility for overriding?

@fabpot fabpot removed the Important label Dec 29, 2014

@anton-kasperovich

This comment has been minimized.

Show comment
Hide comment
@anton-kasperovich

anton-kasperovich Feb 9, 2015

@stof what about Docker and https://docs.docker.com/userguide/dockerlinks/ , there is should be opportunity to set up dynamically parameter values.

I know about import custom parameters.php... , but for changing only two values i should create external file and wrote custom getenv strings (which actually only used in continues integration context)

@beberlei 👍

UPD: Example, one container (admin-backend on sf2) fill data in mongo/redis and another container (frontend on angularjs-silex) read them

docker run -it --link loop-mongo:mongo --link loop-redis:redis --rm loop /bin/sh -c 'echo export SYMFONY__MONGO_DB_SERVER=mongodb://${MONGO_PORT_27017_TCP_ADDR}:${MONGO_PORT_27017_TCP_PORT} >> /root/.bashrc && echo export SYMFONY__REDIS_SERVER=$REDIS_PORT_6379_TCP >> /root/.bashrc && . /root/.bashrc && php app/console doctrine:mongodb:schema:create && php app/console doctrine:mongodb:fixtures:load'

@stof what about Docker and https://docs.docker.com/userguide/dockerlinks/ , there is should be opportunity to set up dynamically parameter values.

I know about import custom parameters.php... , but for changing only two values i should create external file and wrote custom getenv strings (which actually only used in continues integration context)

@beberlei 👍

UPD: Example, one container (admin-backend on sf2) fill data in mongo/redis and another container (frontend on angularjs-silex) read them

docker run -it --link loop-mongo:mongo --link loop-redis:redis --rm loop /bin/sh -c 'echo export SYMFONY__MONGO_DB_SERVER=mongodb://${MONGO_PORT_27017_TCP_ADDR}:${MONGO_PORT_27017_TCP_PORT} >> /root/.bashrc && echo export SYMFONY__REDIS_SERVER=$REDIS_PORT_6379_TCP >> /root/.bashrc && . /root/.bashrc && php app/console doctrine:mongodb:schema:create && php app/console doctrine:mongodb:fixtures:load'
@eddiejaoude

This comment has been minimized.

Show comment
Hide comment
@eddiejaoude

eddiejaoude Mar 3, 2015

Contributor

SYMFONY__ Env Variables overwriten by parameters.yml

A way I got around this was to create a parameters_dev.yml file & put the ENV variable into .dist, then load the dev parameters with config_dev.yml (see below).

Not ideal, but seems to work fine without much change.

# config_dev.yml 
imports:
    - { resource: config.yml }
    - { resource: parameters_dev.yml }
Contributor

eddiejaoude commented Mar 3, 2015

SYMFONY__ Env Variables overwriten by parameters.yml

A way I got around this was to create a parameters_dev.yml file & put the ENV variable into .dist, then load the dev parameters with config_dev.yml (see below).

Not ideal, but seems to work fine without much change.

# config_dev.yml 
imports:
    - { resource: config.yml }
    - { resource: parameters_dev.yml }

@eddiejaoude eddiejaoude referenced this issue in DashboardHub/PipelineDashboard Mar 3, 2015

Closed

Login on heruko redirects to localhost #48

@rodrigodiez

This comment has been minimized.

Show comment
Hide comment
@rodrigodiez

rodrigodiez Mar 28, 2015

+1
Looking forward to see this behaviour implemented. It would allow to easily run parametrized docker containers

+1
Looking forward to see this behaviour implemented. It would allow to easily run parametrized docker containers

@jrobeson

This comment has been minimized.

Show comment
Hide comment
@jrobeson

jrobeson Mar 28, 2015

Contributor

@rodrigodiez : for now, try as @beberlei suggested in #7555 (comment)

Contributor

jrobeson commented Mar 28, 2015

@rodrigodiez : for now, try as @beberlei suggested in #7555 (comment)

@ruudk

This comment has been minimized.

Show comment
Hide comment
@ruudk

ruudk May 7, 2015

Contributor

I really hope that the Container/ParameterBag can be altered so that it would support special ENV parameters. These parameters shouldn't be inlined when generating the cache but always link to a special service that retrieves the value from ENV. When the ENV parameter changes the Symfony2 app should just pickup the change.

This way, it would be much more easier to run Symfony2 apps inside Docker containers and dynamically link dependencies like redis and mysql using Docker Container Links.

@stof @fabpot Would something like this even be possible? I know that parameters can be constructed from other parameters but I think that we shouldn't need that for the ENV parameters.

Contributor

ruudk commented May 7, 2015

I really hope that the Container/ParameterBag can be altered so that it would support special ENV parameters. These parameters shouldn't be inlined when generating the cache but always link to a special service that retrieves the value from ENV. When the ENV parameter changes the Symfony2 app should just pickup the change.

This way, it would be much more easier to run Symfony2 apps inside Docker containers and dynamically link dependencies like redis and mysql using Docker Container Links.

@stof @fabpot Would something like this even be possible? I know that parameters can be constructed from other parameters but I think that we shouldn't need that for the ENV parameters.

@ruudk

This comment has been minimized.

Show comment
Hide comment
@ruudk

ruudk May 7, 2015

Contributor

I just found out that I can use the ExpressionLanguage component and register my own getenv method with something like this:

            new ExpressionFunction('getenv', function ($arg) {
                return sprintf('getenv(%s)', $arg);
            }, function (array $variables, $value) {
                return getenv($value);
            }),
Contributor

ruudk commented May 7, 2015

I just found out that I can use the ExpressionLanguage component and register my own getenv method with something like this:

            new ExpressionFunction('getenv', function ($arg) {
                return sprintf('getenv(%s)', $arg);
            }, function (array $variables, $value) {
                return getenv($value);
            }),
@stof

This comment has been minimized.

Show comment
Hide comment
@stof

stof May 7, 2015

Member

@ruudk this is what I implemented in https://github.com/Incenteev/DynamicParametersBundle (it works in Symfony 2.6.2+)

However, this does not work for parameters used in the semantic configuration of bundles. The semantic config is resolved before being passed to the bundle, and changing this would be a huge BC break (you cannot require a field to contain a boolean value and accept to use parameters in them for instance, as '%kernel.debug%' is a string, not a boolean).

Member

stof commented May 7, 2015

@ruudk this is what I implemented in https://github.com/Incenteev/DynamicParametersBundle (it works in Symfony 2.6.2+)

However, this does not work for parameters used in the semantic configuration of bundles. The semantic config is resolved before being passed to the bundle, and changing this would be a huge BC break (you cannot require a field to contain a boolean value and accept to use parameters in them for instance, as '%kernel.debug%' is a string, not a boolean).

@piotrpasich

This comment has been minimized.

Show comment
Hide comment
@piotrpasich

piotrpasich Jun 23, 2015

Coming back to the first post of @beberlei from 2013 - the issue with overwriting env parameters by parameters.yml might be really painful during deployment automation with different servers (dev, qa, pre-prod, prod) especially on AWS + docker. I would like to avoid adding a special parameters.yml file in every single server when I can use preconfigured environment variables (ex. for database).

@beberlei your solution works and that's awesome. Can we take into consideration change the current behavior and let the environment parameters not be overwritten by anything else? I can live with caching etc.

Just say a word and I will create a pull request.

Coming back to the first post of @beberlei from 2013 - the issue with overwriting env parameters by parameters.yml might be really painful during deployment automation with different servers (dev, qa, pre-prod, prod) especially on AWS + docker. I would like to avoid adding a special parameters.yml file in every single server when I can use preconfigured environment variables (ex. for database).

@beberlei your solution works and that's awesome. Can we take into consideration change the current behavior and let the environment parameters not be overwritten by anything else? I can live with caching etc.

Just say a word and I will create a pull request.

@eddiejaoude

This comment has been minimized.

Show comment
Hide comment
@eddiejaoude

eddiejaoude Jun 23, 2015

Contributor

...I got around this was to create a parameters_dev.yml ...

@piotrpasich I agree. Following that project where I used *_dev etc (mentioned above). I never implemented that again, it created other issues. I am keen for environment parameters not be overwritten.

Contributor

eddiejaoude commented Jun 23, 2015

...I got around this was to create a parameters_dev.yml ...

@piotrpasich I agree. Following that project where I used *_dev etc (mentioned above). I never implemented that again, it created other issues. I am keen for environment parameters not be overwritten.

@weaverryan

This comment has been minimized.

Show comment
Hide comment
@weaverryan

weaverryan Jun 24, 2015

Member

@piotrpasich I would like to see a PR for this indeed :). The trick will be doing this without breaking backwards compatibility. If you can think of a clever way to do that, then we're in great shape!

Member

weaverryan commented Jun 24, 2015

@piotrpasich I would like to see a PR for this indeed :). The trick will be doing this without breaking backwards compatibility. If you can think of a clever way to do that, then we're in great shape!

@paq85

This comment has been minimized.

Show comment
Hide comment
@paq85

paq85 Jul 28, 2015

+1 for this feature

paq85 commented Jul 28, 2015

+1 for this feature

@SchizoDuckie

This comment has been minimized.

Show comment
Hide comment
@SchizoDuckie

SchizoDuckie Aug 5, 2015

+1 for a solid solution for this feature and having a well thought-out and documented plan on how to use it, because the best practices doc just says 'store them in the environment' and provides no further guidance, so people make assumptions and invent their own methods pending the resolving of this ticket.

Some thoughts:

  • putting environment configs in NGinx/Apache would break any CLI scripts (requires double administration)
  • 'put them in your ~/.bashrc with declare' is fragile and leaves edge cases that won't work for devs that work on multiple environments or in non-bash.
  • having a separate bash script that sets the export variables requires double administration that will fail some day because somebody forgets to add a variable.
  • modifying the appkernel.php to load a custom file seems hacky and can conflict with other modules that require parameters.yml to be in a specific spot

We are now just going to symlink a parameters.yml from a directory that's under puppet's control to bypass all of these problems and use no environment variables at all.

+1 for a solid solution for this feature and having a well thought-out and documented plan on how to use it, because the best practices doc just says 'store them in the environment' and provides no further guidance, so people make assumptions and invent their own methods pending the resolving of this ticket.

Some thoughts:

  • putting environment configs in NGinx/Apache would break any CLI scripts (requires double administration)
  • 'put them in your ~/.bashrc with declare' is fragile and leaves edge cases that won't work for devs that work on multiple environments or in non-bash.
  • having a separate bash script that sets the export variables requires double administration that will fail some day because somebody forgets to add a variable.
  • modifying the appkernel.php to load a custom file seems hacky and can conflict with other modules that require parameters.yml to be in a specific spot

We are now just going to symlink a parameters.yml from a directory that's under puppet's control to bypass all of these problems and use no environment variables at all.

nclavaud added a commit to nclavaud/richesterres that referenced this issue Sep 28, 2015

Comment config in parameters.yml.dist for Heroku
Otherwise, Heroku will create a `parameters.yml` file containing these
variables, and environment variables will be overriden.

https://discussion.heroku.com/t/deploying-a-symfony-app-helpful-tips/897
symfony/symfony#7555
@lennerd

This comment has been minimized.

Show comment
Hide comment

lennerd commented Oct 14, 2015

👍

@alu

This comment has been minimized.

Show comment
Hide comment

alu commented Mar 9, 2016

👍

@qdequippe

This comment has been minimized.

Show comment
Hide comment

👍

@backbone87

This comment has been minimized.

Show comment
Hide comment
@backbone87

backbone87 Mar 22, 2016

Contributor

Like already noted, the problem is the resolution context of some variables (parameters). The current behavior of the Config component expects everything to be resolveable at container-build-time (deploy-time). Allowing the use of "unresolved" parameters (parameters that will resolve after deploy-time) within semantic configuration must be handled by the consumers of the configuration (the container extensions), which is a very complex task, if at all possible.
The config component can provide some protection against missconfiguration/missuse though:

<parameter name="host" type="expression" scope="runtime">getenv('HOST')</parameter>

If parameter host is used within a Configuration tree the Config component can throw an InvalidParameterScopeException. But the Configuration tree can also declare the accepted (maximum) scope of an option individually, if it can handle unresolved values for the option.
So, if all Configuration trees that receive a %host% value in one of their options, can handle unresolved parameters in this options, the container-build would succeed.

edit:

<parameter name="host" type="environment" scope="runtime">HOST</parameter>
<!-- runtime scope is implicit for environment parameters -->
Contributor

backbone87 commented Mar 22, 2016

Like already noted, the problem is the resolution context of some variables (parameters). The current behavior of the Config component expects everything to be resolveable at container-build-time (deploy-time). Allowing the use of "unresolved" parameters (parameters that will resolve after deploy-time) within semantic configuration must be handled by the consumers of the configuration (the container extensions), which is a very complex task, if at all possible.
The config component can provide some protection against missconfiguration/missuse though:

<parameter name="host" type="expression" scope="runtime">getenv('HOST')</parameter>

If parameter host is used within a Configuration tree the Config component can throw an InvalidParameterScopeException. But the Configuration tree can also declare the accepted (maximum) scope of an option individually, if it can handle unresolved values for the option.
So, if all Configuration trees that receive a %host% value in one of their options, can handle unresolved parameters in this options, the container-build would succeed.

edit:

<parameter name="host" type="environment" scope="runtime">HOST</parameter>
<!-- runtime scope is implicit for environment parameters -->
@atorian

This comment has been minimized.

Show comment
Hide comment
@atorian

atorian Jun 27, 2016

The possibility to override parameter by passing ENV var looks very interesting.
It will allow having default values for ENV, for example:

parameters.yaml

parameters:
    ...
    database_port: ~

Then docker-compose sets SYMFONY__DATABASE_PORT var and overrides it.

It will add some usability benefits, as the list of env might be quite long.
And it looks safe and easy to implement.

However reading every not prefixed with SYMFONY__ var looks dangerous.
If developer wants to use this vars - he should consider something like this:

parameters.php

<?php
return [
   'parameters' => [
        ...
        'host' => getenv('HOST') ?: 'localhost',
    ],
];

atorian commented Jun 27, 2016

The possibility to override parameter by passing ENV var looks very interesting.
It will allow having default values for ENV, for example:

parameters.yaml

parameters:
    ...
    database_port: ~

Then docker-compose sets SYMFONY__DATABASE_PORT var and overrides it.

It will add some usability benefits, as the list of env might be quite long.
And it looks safe and easy to implement.

However reading every not prefixed with SYMFONY__ var looks dangerous.
If developer wants to use this vars - he should consider something like this:

parameters.php

<?php
return [
   'parameters' => [
        ...
        'host' => getenv('HOST') ?: 'localhost',
    ],
];
@sagikazarmark

This comment has been minimized.

Show comment
Hide comment
@sagikazarmark

sagikazarmark Jul 26, 2016

One possible solution for the "docker problem": create an entrypoint which clears the cache upon every container start (and apply @beberlei's fix). Haven't found a better way so far.

One possible solution for the "docker problem": create an entrypoint which clears the cache upon every container start (and apply @beberlei's fix). Haven't found a better way so far.

@mcfedr

This comment has been minimized.

Show comment
Hide comment
@mcfedr

mcfedr Jul 26, 2016

Contributor

That probably necessary at the moment.
Ideally the cache would be created as part of the build step and so when a container is started its already got the cache - that would give the fastest possible start up time.
I am currently thinking for my own services to inject a getter instead of the parameter directly, that way it will always refer to the environment - but this wont work for existing bundles.

Contributor

mcfedr commented Jul 26, 2016

That probably necessary at the moment.
Ideally the cache would be created as part of the build step and so when a container is started its already got the cache - that would give the fastest possible start up time.
I am currently thinking for my own services to inject a getter instead of the parameter directly, that way it will always refer to the environment - but this wont work for existing bundles.

@sagikazarmark

This comment has been minimized.

Show comment
Hide comment
@sagikazarmark

sagikazarmark Jul 26, 2016

The problem is that you cannot determine the VALUE for the environment variable during build time. So when you want to use service discovery, you need to recompile the cache anyway. I agree that it somewhat violates the docker philosophy, but the only solution would be if we could use dynamic parameters (which you can with the library linked by @stof, but it feels hacky to me). Since the environment should be exactly the same, you can safely recompile the container IMO.

The problem is that you cannot determine the VALUE for the environment variable during build time. So when you want to use service discovery, you need to recompile the cache anyway. I agree that it somewhat violates the docker philosophy, but the only solution would be if we could use dynamic parameters (which you can with the library linked by @stof, but it feels hacky to me). Since the environment should be exactly the same, you can safely recompile the container IMO.

@mcfedr

This comment has been minimized.

Show comment
Hide comment
@mcfedr

mcfedr Jul 27, 2016

Contributor

I agree, its complete safe to rebuild, but it takes time and it would be nice to avoid that. As far as I can tell, without a serious overhaul of the DI component rebuilding will remain necessary.

Contributor

mcfedr commented Jul 27, 2016

I agree, its complete safe to rebuild, but it takes time and it would be nice to avoid that. As far as I can tell, without a serious overhaul of the DI component rebuilding will remain necessary.

fabpot added a commit that referenced this issue Sep 15, 2016

feature #19681 [DI] Allow injecting ENV parameters at runtime using %…
…env(MY_ENV_VAR)% (nicolas-grekas)

This PR was merged into the 3.2-dev branch.

Discussion
----------

[DI] Allow injecting ENV parameters at runtime using %env(MY_ENV_VAR)%

| Q             | A
| ------------- | ---
| Branch?       | master
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets |  #10138, #7555, #16403, #18155
| License       | MIT
| Doc PR        | symfony/symfony-docs#6918

This is an alternative approach to #18155 for injecting env vars into container configurations.

With this PR, anywhere parameters are allowed, one can use `%env(ENV_VAR)%` to inject a dynamic env var. Additionally, if one sets a value to such parameters in e.g. the `parameter.yml` file (`env(ENV_VAR): foo`), this value will be used as a default value when the env var is not defined. If no default value is specified, an `EnvVarNotFoundException` will be thrown at runtime.

Unlike previous attempts that also used parameters (#16403), the implementation is compatible with DI extensions: before being dumped, env vars are resolved to uniquely identifiable string placeholders that can get through DI extensions manipulations. When dumped, these unique placeholders are replaced by dynamic calls to a getEnv method..

ping @magnusnordlander @dzuelke @fabpot

Commits
-------

bac2132 [DI] Allow injecting ENV parameters at runtime using %env(MY_ENV_VAR)% syntax

@fabpot fabpot closed this Sep 15, 2016

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