[Dotenv] add loadEnv(), a smoother alternative to loadForEnv() #29129

nicolas-grekas · 2018-11-07T17:17:26Z

Q	A
Branch?	4.2
Bug fix?	yes
New feature?	no
BC breaks?	yes (4.2-only)
Deprecations?	no
Tests pass?	yes
Fixed tickets	-
License	MIT
Doc PR	-

This PR replaces the loadForEnv() method introduced in #28533 by a new loadEnv() method.

It accepts only one mandatory argument: $path, which is the path to the .env file.
The 2nd argument is optional and defines the name of the environment variable that defines the Symfony env. This plays better with the current practice of defining the env in .env (loadForEnv() requires knowing the env before being called, leading to a chicken-n-egg situation that loadEnv() avoids.)
the possibility to load several files at once is removed. We don't have a use case for it and those who do can call loadEnv() in a loop anyway.

In addition to $path (.env), the following files are loaded, the latter taking precedence in this order:
.env < env.local < .env.$env < .env.$env.local

Note that loadForEnv() used to give higher precedence to .env.local vs .env.$env.
The new behavior is aligned with the order used by create-react-app. It also allows overriding the env in .env.local, which should be convenient for DX.

Last but not least, the "test" env has this special behaviors:

.env.local file is skipped for the "test" env (same as before and as in create-react-app)
~~vars defined in .env files override real env vars (similar to what Rails' dotenv does: you don't want your tests to randomly fail because of some real env vars)~~.

ogizanagi · 2018-11-07T17:40:59Z

Note that loadForEnv() used to give higher preference to .env.$env vs .env.local.
The new behavior is aligned with the order used by create-react-app.

But not aligned with bkeepers/dotenv. See symfony/symfony-docs#10626 (comment)
Not sure which one really is the most convenient one.

vars defined in .env files override real env vars (similar to what Rails' dotenv does: you don't want your tests to randomly fail because of some real env vars).

I'm used to occasionally start phpunit with APP_DEBUG=1 bin/phpunit --filter=[...] to debug some tests (APP_DEBUG=0 is used by default in my tests suites). This will prevent it, right?
What about CI using real env vars?

nicolas-grekas · 2018-11-07T18:08:43Z

But not aligned with bkeepers/dotenv.

Sure. create-react-app has the behavior that best matches Symfony, so why should we care more about bkeepers?

APP_DEBUG=1 bin/phpunit --filter=[...] This will prevent it, right? What about CI using real env vars?

Nope it won't, useless you defined APP_DEBUG yourself in .env (we don't do that by default).
Same for other real env vars: if they're not defined in .env(.*) they'll be used.

ogizanagi · 2018-11-07T18:23:14Z

create-react-app has the behavior that best matches Symfony

Based on which facts? 🤔

unless you defined APP_DEBUG yourself in .env (we don't do that by default).

Indeed. We provided the value in https://github.com/symfony/recipes/blob/5b3ce909504b9366405820c49bc9f0e13ac4be54/symfony/phpunit-bridge/4.1/phpunit.xml.dist#L14, but that's not relevant with planned changes.
Still, if my test suite is meant to be ran by default with APP_DEBUG=0, it'll need to be set in .env.test, so wouldn't be overridable anymore.

Same for other real env vars: if they're not defined in .env(.*) they'll be used.

So, what do you preconize for CI appart from either removing .env(.*) files or not using env vars at all and requiring generating a .env.test[.local] on each build?

nicolas-grekas · 2018-11-07T18:32:35Z

Based on which facts? thinking

You're asking because you think we should keep the current behavior?

My arguments for the new one are:

matching the behavior of create-react-app looks more important than matching the one of a rails app (how often will ppl use both rails+symfony vs symfony+create-react-app?)
as explained in the description, having this order allows defining the env in .env.local - before .env.$env(.local). It wouldn't be that easy without.

if my test suite is meant to be ran by default with APP_DEBUG=0, it'll need to be set in .env.test

yes, this is described in https://metaskills.net/2013/10/03/using-dotenv-in-rails/

Now, one last thing. We need to make sure that our tests do not use any real, development or local environment settings. This is where @ecbypi overload feature comes in handy.

the reason is that tests run in a special set of configuration and the very purpose of .env.test is to commit that configuration. If you don't want to follow what the devs set there, you have to do extra work. OR if your test setup needs to be flexible, you can omit defining those vars in .env files.

nicolas-grekas · 2018-11-07T19:04:39Z

BTW, about the test env: if, for some FOO env var, one would like to give control to the real env while that var is defined in .env, the way to do it would be to add FOO=$FOO in .env.test (or .env.test.local)

dunglas · 2018-11-07T20:00:09Z

The new behavior is aligned with the order used by create-react-app. It also allows overriding the env in .env.local, which should be convenient for DX.

👍 on my side. Many people will use Create React App and Symfony together in the same project, Rails + Symfony will definitely be less popular.

vars defined in .env files override real env vars (similar to what Rails' dotenv does: you don't want your tests to randomly fail because of some real env vars).

Are you sure about that? According to their docs, it's not the case by default, but you can use overload (as in our DotEnv) to have this behavior: https://github.com/bkeepers/dotenv#why-is-it-not-overriding-existing-env-variables

nicolas-grekas · 2018-11-07T22:17:17Z

OK, overloading for test removed. Ready.

ogizanagi

What would it be like in the recipe with the --env re-introduction, though?

Dotenv::loadEnv('.env', 'APP_ENV', $input->getParameterOption(['--env', '-e'], 'dev', true));

? --env would be ignored if APP_ENV env var is set...which is fine to me. Just sayin' :)

nicolas-grekas · 2018-11-08T11:02:03Z

--env would be ignored if APP_ENV env var is set

Right now, --env is considered more specific, so it wins over the env var.
I don't see why we should change that part.

…nv() (nicolas-grekas) This PR was merged into the 4.2-dev branch. Discussion ---------- [Dotenv] add loadEnv(), a smoother alternative to loadForEnv() | Q | A | ------------- | --- | Branch? | 4.2 | Bug fix? | yes | New feature? | no | BC breaks? | yes (4.2-only) | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - This PR replaces the `loadForEnv()` method introduced in #28533 by a new `loadEnv()` method. - It accepts only one mandatory argument: `$path`, which is the path to the `.env` file. - The 2nd argument is optional and defines the name of the environment variable that defines the Symfony env. This plays better with the current practice of defining the env in `.env` (`loadForEnv()` requires knowing the env before being called, leading to a chicken-n-egg situation that `loadEnv()` avoids.) - the possibility to load several files at once is removed. We don't have a use case for it and those who do can call `loadEnv()` in a loop anyway. In addition to $path (.env), the following files are loaded, the latter taking precedence in this order: .env < env.local < .env.$env < .env.$env.local Note that `loadForEnv()` used to give higher precedence to .env.local vs .env.$env. The new behavior is aligned with [the order used by create-react-app](https://github.com/facebook/create-react-app/blob/master/docusaurus/docs/adding-custom-environment-variables.md#what-other-env-files-can-be-used). It also allows overriding the env in .env.local, which should be convenient for DX. Last but not least, the "test" env has this special behaviors: - `.env.local` file is skipped for the "test" env (same as before and as in create-react-app) - ~vars defined in .env files **override** real env vars (similar to what Rails' dotenv does: you don't want your tests to randomly fail because of some real env vars)~. Commits ------- 0cf9acb [Dotenv] add loadEnv(), a smoother alternative to loadForEnv()

nicolas-grekas added this to the 4.2 milestone Nov 7, 2018

carsonbot added Status: Needs Review Bug BC Break labels Nov 7, 2018

nicolas-grekas force-pushed the dotenv-loadenv branch from 521236f to 0622753 Compare November 7, 2018 18:10

nicolas-grekas force-pushed the dotenv-loadenv branch from 0622753 to e2af3b9 Compare November 7, 2018 22:16

dunglas approved these changes Nov 7, 2018

View reviewed changes

carsonbot added Status: Reviewed and removed Status: Needs Review labels Nov 7, 2018

ogizanagi approved these changes Nov 7, 2018

View reviewed changes

nicolas-grekas force-pushed the dotenv-loadenv branch from e2af3b9 to d7d786b Compare November 8, 2018 08:49

[Dotenv] add loadEnv(), a smoother alternative to loadForEnv()

0cf9acb

nicolas-grekas force-pushed the dotenv-loadenv branch from d7d786b to 0cf9acb Compare November 8, 2018 11:51

nicolas-grekas mentioned this pull request Nov 8, 2018

Allow to override .env files per env symfony/recipes#481

Merged

Tobion approved these changes Nov 9, 2018

View reviewed changes

nicolas-grekas merged commit 0cf9acb into symfony:master Nov 9, 2018

nicolas-grekas deleted the dotenv-loadenv branch November 9, 2018 08:18

fabpot mentioned this pull request Nov 16, 2018

Release v4.2.0-BETA2 #29237

Merged

cmodijk mentioned this pull request Mar 3, 2021

The symfony:dump-env does not take in account the testEnvs symfony/flex#747

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Dotenv] add loadEnv(), a smoother alternative to loadForEnv() #29129

[Dotenv] add loadEnv(), a smoother alternative to loadForEnv() #29129

nicolas-grekas commented Nov 7, 2018 •

edited

Loading

ogizanagi commented Nov 7, 2018

nicolas-grekas commented Nov 7, 2018 •

edited

Loading

ogizanagi commented Nov 7, 2018

nicolas-grekas commented Nov 7, 2018 •

edited

Loading

nicolas-grekas commented Nov 7, 2018 •

edited

Loading

dunglas commented Nov 7, 2018

nicolas-grekas commented Nov 7, 2018

ogizanagi left a comment

nicolas-grekas commented Nov 8, 2018

[Dotenv] add loadEnv(), a smoother alternative to loadForEnv() #29129

[Dotenv] add loadEnv(), a smoother alternative to loadForEnv() #29129

Conversation

nicolas-grekas commented Nov 7, 2018 • edited Loading

ogizanagi commented Nov 7, 2018

nicolas-grekas commented Nov 7, 2018 • edited Loading

ogizanagi commented Nov 7, 2018

nicolas-grekas commented Nov 7, 2018 • edited Loading

nicolas-grekas commented Nov 7, 2018 • edited Loading

dunglas commented Nov 7, 2018

nicolas-grekas commented Nov 7, 2018

ogizanagi left a comment

Choose a reason for hiding this comment

nicolas-grekas commented Nov 8, 2018

nicolas-grekas commented Nov 7, 2018 •

edited

Loading

nicolas-grekas commented Nov 7, 2018 •

edited

Loading

nicolas-grekas commented Nov 7, 2018 •

edited

Loading

nicolas-grekas commented Nov 7, 2018 •

edited

Loading