-
-
Notifications
You must be signed in to change notification settings - Fork 625
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to silently ignore missing env config #52
Comments
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 Naturally, the easy way to implement this yourself is with a check: if (is_file(__DIR__ . '/.env')) {
Dotenv::load(__DIR__);
} |
@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 |
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 |
@vlucas where do you keep 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). |
@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. |
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. |
Vance, thanks for your input. One question, where is your if(BULLET_ENV == 'development') {
Dotenv::load(dirname(__DIR__));
} |
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 |
Gotcha. |
I'd love an option to ignore missing environment config.
Let me explain the use case.
.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..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.The text was updated successfully, but these errors were encountered: