I don't get what's the purpose of having.env.prod while at the same time discuraging or even blockingDotEnv usage on production 🤔 Also, development instances shouldn't use production configuration..env.prod should not be commited, nor included in built Docker image. So what is the use case for it?

I don't like the idea of this PR. It makes simple task (app configuration) much more complicated and IMO doesn't bring added value (the only one I see is configuring variables for different environments and use it only by changingAPP_ENV, without need to edit.env by commenting/uncommenting lines per environment). I thought that YAML files' split (packages inprod/dev subdirectories) and.env file were supposed to fulfill all the config scenarios. This is a step back for me.

But maybe I don't understand something..

The first use case I have is to have on a local machine the dev and test environments running at the "same" time. I mainly have a differentDATABASE_URL env variable which is probably different per developer and I don't want to useDATABSE_URL=... vendor/bin/simple-phpunit!

@Wirone .env.prod is totally optional (for people not able to set environment variables in prod). This file will not be generated by the default skeleton (only .env.test will).
However it will make easier to use Dotenv in prod in cases were there is no alternatives (shared servers usually, and even for jobs in dedicated servers without Docker/K8S).

However, having .env.test, .env.panther, .env.otherenv on the development machine will be very useful (and it’s my main goal, as I use Kubernetes in prod, without env files obviously).

I think what's missing from this picture is where.dist files fit in. We should not follow blindly the Create React App / Rails way, because it conflicts with our conventions.

@teohhanhui the whole point of this PR is to switch from “our” conventions to the ones other projects follow.
Basically, .env.dist is now .env, and .env is now .env.local.

That sounds like a really bad thing to me. We shouldn't just switch conventions like that. What's wrong with sticking with.dist? It makes it more explicit that it's a distribution file. Plus, this would not go well with Docker Compose (.env is special for Docker Compose).

What I'm trying to say is, we could stick with our conventions while having all the benefits of an extended .env support like in the other projects.

This has already been discussed a lot insymfony/recipes#466 and related tickets. It actually makes it easier to deal with Docker Compose.

Thank you@dunglas.

did we really need this?

Why .env.prod over config/packages/prod? if you cant define real env vars those locations are effectively the same already... and you can already import a git ignored local parameter file.

the behavior of Create React App, Rails' DotEnv and probably some other libs:

so yeah.. curious if the config/packages/ convention didnt already provide such behavior in SF.

Is there a well-defined use case for this to explain why it's useful? The only ones I can think up are already solved by using parameters and environment variables as they are in Symfony 4.1, but I could well be missing something.

In my projects we havephpunit.xml.dist and.php_cs.dist files committed and their non-dist versions ignored, so the convention adopted from Rails etc just brings another convention into play, rather than replacing one. It's understandable if a lot of others are already used to this convention, but it's the first time I've seen it.

Just my 2 pence!

This feature has a lot of options in it, but the original motivation was to help solve exactly one problem. Currently, you need to add all of your environment variables inphpunit.xml.dist. So, your environment variables are completely duplicated, even if you only want to change a few environment variables. This + this WIP recipe (symfony/recipes#466) will help make that happen (as you can just have a.env.dist). I think that, mostly, this change will not mean much to people - other than you don't need to duplicate your env vars in the test environment anymore and can instead create a.env.test with only the overrides.

Cheers!

still.. there's zero difference with doing

# config/packages/test/some.yamlenv(SOME): "default in test"

no?

The value can be changed without invalidating the container, that's the diff :)

That's a VERY fair point@ro0NL :). But I think setting a default in that way is a bit less obvious than having a.env.test that's created for you when installing the simple-phpunit recipe.

@weaverryan right!, that's the 2nd difference: flex automation!

understood. im just skeptical if the overhaul is worth it eventually, it's quite significant.

@weaverryan Thanks for this! We were starting to think we'd gone mad and had completely missed something.

Hi,

This "Ruby's dotenv behavior" is BC for all tools using ".env traditional behaviour" which is to store a lot of command lines arguments value andstore secrets.

My main difficulty is with this last point. Cf.What Changed Exactly?

B) The .env file is now commited to your repository.

Check this illustration withdocker-compose to build the followingDockerfile :

FROM registry.access.redhat.com/rhel7/rhelARG PASSWORD

With the following tips Cf.docker compose args

You can omit the value when specifying a build argument, in which case its value at build time is the value in the environment where Compose is running.

services:web:build:context:docker/webargs:                -PASSWORD

And command line ".env traditional behaviour"explain Cf.docker compose env

Compose supports declaring default environment variables in an environment file named .env placed in the folder where the docker-compose command is executed (current working directory).

Will proposedocker-compose to adopt "Ruby's dotenv behavior"

extra thoughts

• a dot file is hidden on Unix FS
• .env is a conventional name shared across multiple tools
  best practice is to use command / service (.composer / .nvm /.java )
  why not.symfony ?
• I used to createlocal environment on my desktop and keepdev for integration on shared dev server, so weird result.env.local.local