Overriding Apache env variables

[vlucas]

Overriding Apache env variables

[vlucas]

The primary advantage with the current approach is that it makes the variables more easily exportable to shell variables.

export APP_ENV='staging'
export DATABASE_URL='sqlite::memory::'

Allows you to do this in the local shell:

eval $(cat .env)

Of course if you use comments and other things, then it might not be so straightforward.

[vlucas]

That said, I definitely feel weird about a bunch of special parsing rules, and I do think this project would benefit from the option of a PHP file include as well.

[levacic]

Ah, didn't even know I could do that - it isn't mentioned anywhere in the docs, and I just dug through the source code right now to verify it. I personally don't see a use case for that - but to be complete, if your file was:

<?php

return [
    'APP_ENV' => 'staging',
    'DATABASE_URL' => 'sqlite::memory::'
];

you could do something like:

eval $(php -r 'foreach (require ".env" as $key => $value) { echo "export {$key}={$value}\n"; }')

Now, I wouldn't ever do this, and it is a bit ugly, and far more complicated than eval $(cat .env), but it's just a proof of concept that a one-liner is possible here as well, if you need it for some deployment process or something - additionally, it doesn't even matter if you have comments or whatever, since PHP already knows how to parse PHP files, so we don't need to write our own parser as we do for the current syntax.

So anyway, you'd be willing to accept a PR that allows PHP files to be used as well? This wouldn't be too complicated actually - we could refactor these lines into a few methods with some detection logic for whether we have a PHP file or not (for example by checking if it starts with <?php, since a valid .env file, according to the current syntax, can't start with that - or just checking if the passed configuration filename ends with .php), and using the appropriate "loading" method afterwards - and this would be completely backwards compatible as well.

Thanks for your input!

P.S. I now realize my mistake when creating this issue and writing about different things, and I'll make sure not to do that again - but what do you think about the apache_setenv() addition - would that make sense? I'm happy to make both PRs, if you think they'd be welcome.

[kelvinj]

@levacic @vlucas

Running source .env should load the environment variables into the shell as well.

If you really want to use PHP, then you can avoid using load() and instead call Dotenv::setEnvironmentVariable() in a PHP file.

Re: the apache bug – I never realised that existed… interesting. I think it'd be difficult to get around it with a solution that doesn't then become confusing. Could it have weird knock-on consequences for Apache?

Definitely think it's worth documenting though, that could catch some people out.

Also, you can use Dotenv::findEnvironmentVariable() to get an environment variable, and it checks the $_ENV first. If that's too verbose, you could create your own wrapper function, e.g. function findenv()

[GabeMedrash]

Forgive me for reviving a long-dormant issue, but the original issue raised by @levacic regarding Apache env variables is unresolved. Considering the docs claim that Dotenv::overload overrides existing environment variables, I had thought this issue had been solved. The problem, however, is reproducible just as @levacic noted:

1. SetEnv FOO bar in Apache configuration
2. Set FOO not_bar in my project's .env
3. Use $dotenv->overload();
4. echo getenv(FOO) => 'bar' (I expect--and want--'not_bar'!)

The solution, as noted, is to check if the apache_setenv function exists (and, if you want, check if apache_getenv returns truthy), then use apache_setenv.

Is there a reason why you wouldn't want to support this feature?