Option to silently ignore missing env config

[vlucas]

Option to silently ignore missing env config

[reinink]

I actually see this being helpful as well, and I'm curious to get @vlucas thoughts on this.

I use phpdotenv in my development environement to set configuration settings. However, in some production environments these variables are already set another way, and the .env isn't needed. For example, Heroku allows you to specify environment variables via their control panel.

Naturally, the easy way to implement this yourself is with a check:

if (is_file(__DIR__ . '/.env')) {
    Dotenv::load(__DIR__);
}

[kamazee]

@reinink yep, that's exactly what I did as a workaround. I would discourage doing so, though: client code is not supposed to know anything about where environment variables are actually written, especially in the light of possible support for multiple backends

[vlucas]

phpdotenv is not meant to be used in production - it is meant to load environment variables in development, so you can simulate production without going through the hassle. I personally do this:

// Load required environment variables from .env in development
if(BULLET_ENV == 'development') {
    Dotenv::load(dirname(__DIR__));
}

// Required ENV vars for this app in production
Dotenv::required([
    'DATABASE_URL',
    'GOOGLE_PLACES_API_KEY',
    // ...
]);

So I still include the phpdotenv library in production to check required ENV variables, but don't load or parse a .env file in production, as this would happen on each request, and would impact perofrmance.

[kamazee]

@vlucas where do you keep DATABASE_URL, GOOGLE_PLACES_API_KEY etc themselves?

Frankly speaking, I don't think parsing a small text file can possibly impact performance that badly (even if it's going to be the only file that is loaded/parsed in a real-life project, it's very likely to get into OS cache, so it won't even cause IO; parsing overhead is really negligible).
On the other hand, it simplifies configuring application by introducing a configuration storage that is untied from both the application itself and the entry point (e.g. database credentials can be written only once for all entry points -- e.g. web and CLI -- and outside of the application which makes deployments easier to maintain and less error prone).

[kamazee]

@vlucas so, rephrasing my previous comment: I think phpdotenv is great in its simplicity and it totally can be used in production because it simplifies some important things while introducing just a tiny overhead.

[vlucas]

I do agree that it can certainly simplify things on production, especially if you're not using a cloud provider. On Heroku and other cloud providers though, you just set the ENV variables once, and any server or CLI command you run after that will have those ENV vars loaded. That's why I don't use phpdotenv to load a .env file in production personally.

[reinink]

Vance, thanks for your input. One question, where is your BULLET_ENV variable being set?

if(BULLET_ENV == 'development') {
    Dotenv::load(dirname(__DIR__));
}

[vlucas]

I define it a few lines above that in the main index.php that bootstraps the whole application.

define('BULLET_ENV', $request->env('BULLET_ENV', 'development'));

It's from an expected environment variable, with a default to 'development' if not set. It's called BULLET_ENV because I use my own Bullet Micro-Framework.

[reinink]

It's from an expected environment variable, with a default to 'development' if not set.

Gotcha.