Option to silently ignore missing env config

[kamazee]

I'd love an option to ignore missing environment config.

Let me explain the use case.

1. I usually keep .env out of application directory (e.g. one level higher than application code that is installed as a package or checked out from the repository) because I think it's easier to maintain the application this way: I can safely lose the directory with all the code (accidentally or not) and nothing breaks as long as it gets to the same state after installing a package or cloning a repository.
2. This kind of environment configuration (.env) is quite useful in production and development environments but barely in test environment where the application is not always supposed to actually run and the environment is not provisioned, so there's basically nobody to write that .env (conceptually), so I usually make CI server set real environment variables while running tests rather than make it write .env and put it where the application usually looks for it.

Well, looks like a lot of typing for a really tiny feature that I envision as another optional argument for static load method. I would have created a PR by this time, but I doubt it makes a lot of sense until v2 (#44) is merged, so I'll probably revisit this tiket later or just kindly ask to add it to that massive set of v2 changes.

[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.