Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!

If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

@taylorotwell that's fair enough. Do you consider #28854 a bug that needs fixing (and would like to see a different solution)? Or is it something you'd like to leave unchanged for now?

Mentioning @driesvints as he tagged the original issue

Thanks :)

@rdarcy1 I'll ping Taylor about it.

After reviewing again I don't think I plan to change anything here. If you do --env=foo and the framework loads .env.foo... and that .env.foo file contains an APP_ENV=bar... I don't see that as a major framework bug?

If you do --env=foo and the framework loads .env.foo... and that .env.foo file contains an APP_ENV=bar... I don't see that as a major framework bug?

@taylorotwell The "issue" is that if you do --env=foo and the framework loads .env.foo and that .env.foo file contains an APP_ENV=bar, the App::environment() method will still return foo instead of bar.

@redelschaap in this situation your --env flag takes precedence over your APP_ENV setting. You need to make sure that APP_ENV matches your .env.<name>

@driesvints That's the whole point. As a developer, I would expect more flexibility to choose the .env file the framework will load when running an artisan command.

A real life use case would be that I run php artisan migrate --env=predeploy to test migrations against a database copy from the production database, just before releasing a new version. In my application, I have a few if-statements to check on the environment, which is set to production, according to APP_ENV in both .env and .env.predeploy. However, the application thinks it's environment is now predeploy and thus the application is behaving differently.

For me, it would help when artisan supports an option that would only set the .env file, but not the environment. Of course, the current behaviour of --env doen't need to be changed.

@redelschaap whilst I think this PR solves a problem, I don't think it's a massive issue for it not to be merged as you can solve the issue in other ways. I imagine we're in a small minority of people who would make use of this so I can see why it's not been accepted (benefit vs added complexity).

In your example, you could create an isProduction() helper or macro and check for multiple environment values.

Alternatively, in your CI script you can just copy the env files as needed:

cp .env.predeploy .env
php artisan migrate # no --env needed
...
rm .env

--env=testing doesn't work at all for me. It does not load .env.testing but it loads .env - my dev DB is now gone and my testing DB remains unprovisioned

for me it works :

php artisan --env=testing env
Current application environment: testing

php artisan --env=testing tinker --execute="dd(config('app.env'))"
"testing"

php artisan --env=local tinker --execute="dd(config('app.env'))"
"local"

check what value you have for APP_ENV in your .env.testing, if you have local, it will use the local db and not the testing db

And btw it's a 2019 issue from L5.9 it's not relevant to post here i think

tinker, env and --execute don't even exist for me - but the APP_ENV in .env.testing contains testing. Probably has something to do with the fact that I'm using Lumen though? 🤔

And yeah, sorry for gravedigging.