[dotenv-rails] .env.local should be loaded in test environments

[ghost]

Hi (and since it is my first contribution to the project: thank you maintainers for Dotenv !)

#280 removed .env.local from the files loaded by Dotenv when Rails is loaded in the test environment.

As discussed in the last comments on the PR, that behavior can be unexpected and is too restrictive for some legitimate (common ?) setups. Having to duplicate variables from .env.local to .env.test.local on the grounds that .env.local should not be used in test environments doesn't really make sense in my opinion. Also, it is up to developers to make sure they configure their CI correctly, I don't think Dotenv should or even can strictly enforce what files are used for what. The documentation is already very clear about what should be ignored from git, and why, and maybe it is enough ?

I created at PR implementing the change: #417

I understand that changing the behavior of Dotenv on that point is tricky because it would probably break things in some projects that rely on .env.local not being loaded for tests, and I hope there is a way forward nonetheless.

Thanks for your time :)

Dotenv: v2.7.6

[fschwahn]

Just stopping by to second this. It's counter-intuitive that there's such a special case for .env.local. In my case, database / redis ports live in .env.local, which applies to all (ie. development & test) environments. It means I have to copy everything over to .env.test.local and always remember to make changes in both files.

[ghost]

Maintainers, I would be grateful for your feedback on this issue :)

If the change of behavior introduced by the attached PR is a blocker, and turning it into a conditional, opt-in feature would help, I would gladly amend the PR.

[codedeleter]

Any chance this could get in? I also find the current behavior very unintuitive.

[ghost]

Hello maintainers, friendly ping in the hope of getting your feedback on the issue :)

[ghost]

Hi maintainers, is there a reason why, several months later, this issue still has no feed-back from you ? Again, I would understand if the issue is not a priority or not even a desired change. If that is the case, I'll simply maintain my own fork and be done with it. If not, is there a way forward ?

[jjercx]

I just had same error. Expecting .env.local to be used while running tests, but surprised when it was actually reading .env

I was going to say "docs should be updated" yet I just noticed:

Local overrides. This file is loaded for all environments except test.

Yet, I was confused by the Wherever the file is under environment. Probably the except test should be there as well

[codyrobbins]

Yup, I’m in the same boat—this behavior makes no sense, breaks expectations, and makes you manually keep values in sync across multiple files for no discernible benefit or reason.

[ktimothy]

Just to contribute to the issue and keep it alive: this is extremely counter-intuituve behaviour with no good rationale behind it. Let's just fix it, it does not sound like a hard think to improve. You even have an existing PR! =)

[fschwahn]

Not to pile on, but even the original author admits that this quite an opinionated behavior, and would be fine with reverting it: #280 (comment)

[dgm]

I too just got bit by this... I have my local database credentials in .env.local and was quite surprised that my tests would not work.

[bkeepers]

In dotenv 3.0, you can customize the files you want loaded. See Customizing Rails. I'm hoping to have that release out soon.

Until then, you can always add Dotenv.overload ".env.local" in config/environments/test.rb or your test helper.

cc #468

[codyrobbins]

While it’s great that 3.0 will allow overriding this behavior, I still respectfully think this change should be reverted completely. The problem here is really that the default behavior makes no sense for most people. Instead of requiring custom configuration straight out of the box to undo a poorly considered change, I think it’s preferable to have it work by default in a way that doesn’t break expectations and then allow those with the non-majority use cases to make use of overrides to customize the behavior to suit their needs. As it is we’re basically left with an override to override a hard-coded override that shouldn’t even exist in the first place.

[bkeepers]

@codyrobbins I hear you and understand where you're coming from. Unfortunately, reverting it will likely cause harm to people that rely on the current behavior, and I'm not willing to risk it. Worst case scenario, imagine someone has DATABASE_URL=… set to their production database in .env.local (I know, terrible idea), and then runs rails test. They've done this a million times in the last 5 years to test production data in development and it's fine (they tell themself), but someone on their team recently upgraded dotenv and now their production database is gone. dotenv is too widely adopted to risk this change.

If consistency is what you want, I would sooner drop support for .env*local entirely than revert the change. Variables not getting set will cause less harm than varibales getting set to unexpected values.

It's a one line change to your app for anyone that disagrees.

[byronbowerman]

IMO it's worth noting that rails has had an environment check designed to prevent just that sort of eventuality.

[bkeepers]

IMO it's worth noting that rails has had an environment check designed to prevent just that sort of eventuality.

It checks that !Rails.env.production?, but that’s not the issue here.

[fschwahn]

No, it's more nifty than that. It checks in which environment the database was created (this is stored in a metadata table in the DB itself), and prevents dropping it in case it is a production DB. See rails/rails#22967

[bkeepers]

@fschwahn nice, I’d did realize that.

Still, it only protects your database. People could have credentials to other production services, so my reasoning is the same. I’m not willing to risk it.

[fschwahn]

FWIW I think this is very sound reasoning. It's unfortunate that this was introduced in the first place, but I understand that it is hard to change now.

[byronbowerman]

I'm not thrilled with it, but I understand, especially since it seems easy enough to deal with.