Make file loading optional

[vlucas]

Make file loading optional

[mikehaertl]

Hmm, but then you have a chicken-egg problem: In dev mode you would use Dotenv to set env vars, so you can't set APP_ENV in the first place.

I really can't see the drawback if Dotenv would be more relaxed in regard to .env: If it's there, load it. If not - ignore anything Dotenv related.

Of course I can add a if (file_exists('.env')) - it's just some extra inconvenience. Maybe I see something in Dotenv that it doesn't want to be: A transparent drop-in replacement for environment vars. It should only do something if .env exists - and stay out of the way if no such file is present.

[mikehaertl]

@vlucas Maybe I have a big misunderstanding here (I'm new to dotenv) but I was very very surprised that this .env file is mandatory. I thougth, that's the point of dotenv:

• Use a .env file in your local environment
• Use "real" env vars in production (no .env required there!)

I find it very weird, that there's an extra check required in my code, whether .env exists. I think, the library should handle this transparently.

Or am I completely missing the point here?

[madsem]

@mikehaertl this is exactly the problem I was just trying to wrap my head around.
(Also completely new to dotenv)

And this is still actual, so I assume it's okay to comment in this old issue.

The way I solved it now was to just reverse the statement and check if APP_ENV is not in production.
i.e:

/*
 * PHP DotEnv initialization
 *
 * Production expects to have everything in the .env exported,
 * as actual environment variables on the server(s)
 */
if(getenv('APP_ENV') !== 'production') {
    $dotEnv = new Dotenv(dirname(__DIR__));
    $dotEnv->load();
}

Not quite sure if this is the recommended way of using it @vlucas ?
Sorry if I'm asking something obvious, it just really is unclear to me right now and it seems also to others, at least judging by what I read over the last 2 hours Googling this :D.

PS: Doesn't that also mean that dotenv should be installed with the dev flag for composer?!

composer require --dev vlucas/phpdotenv

[vlucas]

@sagikazarmark that makes perfect sense. I do exactly that. In fact, this is real code I just copied from a live application of mine running on bullet:

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

// ...

// Load required environment variables from .env in development
$dotenv = new Dotenv\Dotenv();
if(BULLET_ENV == 'development') {
    $dotenv->load(dirname(__DIR__), 'dev.env');
}
// Required ENV vars for this app in production
$dotenv->required([
    'DATABASE_URL',
    'PATH_FILE_UPLOADS',
    'GOOGLE_PLACES_API_KEY',
    'RAVEN_DSN',
    'MANDRILL_USER', 'MANDRILL_PASS'
]);

[sagikazarmark]

Also, related to the CLI context: wouldn't it be better to use getcwd() instead of __DIR__?

[vlucas]

Step 2 in your new flow with dotenv can be changed to running a single command:

source .env

[sagikazarmark]

Of course it can be, that was just an example of setting up variables in our environment. Thanks anyway. :)

[sagikazarmark]

@vlucas Anything to add here?

[vlucas]

I think Dotenv is always going to expect the file to exist. You could either try/catch, or just check it yourself:

if (file_exists($envDir . '.env')) {
   $dotenv->load($envDir);
}

[vlucas]

Of course, the other solution might be something like:

$dotenv->loadIfExists();

[sagikazarmark]

That's what I was hoping ;)

[kelvinj]

$dotenv->loadIfExists();

and then

$dotenv->overloadIfExists();

feels like overkill.

I'd rather check the file exists or wrap it up in a try … catch as Vance said.

[vlucas]

You generally should only be using Dotenv for development and/or testing, e.g.:

if(getenv('APP_ENV') === 'development') {
    $dotenv = new Dotenv\Dotenv();
    $dotenv->load(__DIR__);
}

This is why the .env is generally always expected to be present.

[kelvinj]

Despite Vance being quite resolute in saying that this should not be used in production, that is a subjective viewpoint that has no bearing on how people actually use dotenv.

I think you have 2 camps:

1. People who use it in development to simulate production environment variables
2. People who use it in all environments to put their app in a known state so they don't have to rely on external environment variables.

The first camp, right now, has to check for the file as it's optional. However if you were to make the suggested change you would just be forcing the second camp to do the check to ensure the file is present.

Such a pointless change and one you could argue over until the cows come home.

[sagikazarmark]

I agree with @vlucas: using dotenv in production SHOULD be avoided if POSSIBLE. The extra file loading is overhead. That said, it is just not possible in some cases.

However it doesn't really matter for example in case of a console application.

[sagikazarmark]

@vlucas related to the recommended usage, I just realised something: Dotenv is not just able to load AND validate env variables, it can do valdation on it's own.

So here is how I would modify the "official" recommendation (as an option, since validation is not necessary):

$dotenv = new Dotenv\Dotenv();
if(getenv('APP_ENV') === 'development') {
    $dotenv->load(__DIR__);
}
$dotenv->required('OTHER_VAR');

This allows us to skip file loading, but not the validation.

Does that make sense?

[koenpunt]

I've created a PHP extension to handle .env files in production. Its still very beta, and could use some testers, so if anyone wants to give it a go: https://github.com/koenpunt/php-dotenv

[vlucas]

I think this has been sufficiently answered, so I am closing this for now.

[armetiz]

Hi there,

On master branch (and all latest branches & 2.0.1), the Dotenv constructor should take directory and file name.

Using a conditional to use load or not seems weird.

$dotenv = new Dotenv\Dotenv(dirname(__DIR__) . '/etc', 'config.env');

if(false === $isProductionEnvironment) {
    $dotenv->load();
}

$dotenv->required(['FOO']);

Should constructor be updated to avoid parameters ?

Regards