Laravel recipe shouldn't have shared file .env

[SanderSander]

In the laravel recipe the .env file is defined as shared file on any environment and therefor is always there while it shouldn't! Dotenv loads the environment variables from .env into $_ENV, $_SERVER but i guess the most of the time the .env is just a empty file and hopefully not used on production environments

// Laravel 5 shared file
set('shared_files', ['.env']);

Also from the documentation Usage notes of dotenv
https://github.com/vlucas/phpdotenv#usage-notes

phpdotenv is made for development environments, and generally should not be used in production. In production, the actual environment variables should be set so that there is no overhead of loading the .env file on each request. This can be achieved via an automated deployment process with tools like Vagrant, chef, or Puppet, or can be set manually with cloud hosts like Pagodabox and Heroku.

[antonmedv]

Can you make PR for it?

[SanderSander]

Of course, will do it somewhere today

[SanderSander]

Ok PR is there.

I noticed that there was a test/recipe/LaravelTest.php but couldn't find it anywhere in the source on the master branch, so I assume it was removed.

6b69e8f

[pelletiermaxime]

I disagree with this. I think in most environments (except prod) it's helpful to automatically have a shared .env. In production you should just not create the .env file, so it won't be shared.

[SanderSander]

I rather explicit define on which environments I want to use dotenv, than doing it implicit.

[oanhnn]

In a lot of cases, you can't modified environments (sharing host). .env is solution.
If you don't want use it, you can using an empty .env file.

[SanderSander]

You're right on the shared hosting part, I was actually a bit surprised to see .env files on the servers because I only use it for development environments all private configuration on staging/production is done in the environment itself, and I'm not really used anymore to shared hosting to be honest.

It's simply solved by adding set('shared_files', []); to the deployment script.

The only reason I don't want the .env file is because I don't want others to think they can use that .env file to fix some mis configuration on staging or whatever it's cleaner to don't have it when not used.

[badconker]

How you can do php artisan migrate without .env file ?

[SanderSander]

@badconker You can set your environment variables in one of the following files ~/.bashrc, /etc/environment and /etc/bash.bashrc (use google for more info).

Or you can do it manually with export VAR=VALUE to make the environment variables available for all sub processes in your current bash session

[badconker]

@SanderSander Ok but these variables are only accessible from terminal no ? So you define your environment variables twice ? One time for php from webserver and one time for php from command line ? I can't use /etc/environment because i need different variables for each virtual host.
Sorry for the off-topic but i'm looking for 2 days how declare my environnement variables to be accessible from php from http request and from php cli. 😕

[oanhnn]

@badconker Using .env file is safe for other applications. If set environment variables in /etc/environment or ~/.bashrc, ... then other applications (other Laravel app, bash or a progam, ..) can parse it as environment variables for them. You will more difficult to control that.

Other option, use SetEnv in apache and fastcgi_param in NGINX to set environment variables in virtual host configure. You can search on Google.

[philbates35]

What do you suggest in the case where there are multiple Laravel applications running on the same server?

For web requests, I could set them in each application's SetEnv directive so that's no problem, but what would I do for artisan commands?

Let's say that both application require ten different environment variables to be set (DB_NAME, DB_PASS etc). How do I run php artisan migrate for one client? This is possible when using the .env file for each application in production. But without the .env file... the only way I can think of is execute artisan commands like export DB_NAME=db_name && export DB_PASS=mysecretpass && ... && php artisan migrate which clearly this isn't a good solution.

Any ideas?

[SanderSander]

@philbates35 Every laravel application could have a separated user, every user has his own environment variables.

So if you want to run an artisan command for your 7th application you just switch to user laravel-app7 and do your things.

Apparently using .env on production for laravel applications is an acceptable way of getting things done, so i would suggest using it if it doesn't really matter.

[badconker]

So you confirm : if we don't want use .env file, we must declare variables twice ? (one in user environnement and one in apache/NGINX configuration file ? We can't get user environnement variables from PHP, no ?)

[pelletiermaxime]

No, you only need to set it in your Apache virtualhost config or for nginx I usually set it in the php-fpm config.

[barryvdh]

A bit late reply, but you should cache your configuration. Imho you should still share the .env file, because it's very convenient. Caching the config will load the .env contents and write it to a cache file. This doesn't use environment vars anymore. (At least in 5.2+)