Drop .env support?

[paulmelnikow]

I was using Shields as a demo of node-config and realized there was something about our setup that I couldn't explain.

Namely, we're using dotenv to read config from env vars using a .env file. This could be more convenient than setting env vars on startup, for example in unusual self-hosted deploy environments where you want to check in the config via a deploy commit. Same goes in dev, where you might want to persist some custom config as you use the software.

However, in both of those environments, setting config is equally possible by checking in a local.yml. This uses our more expressive config schema instead of the env vars.

The purpose of the env var mapping is really to provide a convenient way to manage config through env vars rather than a in a (config) file. So the time to use it is when you don't want to check in config. If you are checking in / storing config in a file, the preferred way to do it would be through a local.yml.

Does that make sense?

I'd propose we remove the dotenv support, and perhaps clarify that local.yml is the preferred / only supported way to manage config through the file system.

[PyvesB]

This makes sense to me, I agree that we should drop .env support.

Some existing self-hosted users may use that configuration format, so we should probably first communicate about it, put a deprecation warning on startup for a few weeks/months, and then finally completely drop support.

[PyvesB]

He's a suggested battle plan:

• post an accepted discussion answer summarising our decision and linking to the appropriate documentation to make migrating easy.
• add a code check to log a deprecation warning when the server starts up and a .env file is found.
• communicate about our intention of dropping dotenv support, via a Tweet and Discord message pointing back to this discussion.
• wait a month.
• remove the dotenv dependency and related code.

Happy to take this on.

[chris48s]

I'm not sure if we've done it before or not, but logging deprecation warningd on startup as a method of communicating non-BC changes for self-hosting users is a good plan in general 👍

[paulmelnikow]

In the long run, I'm not sure we need to bend over backwards to avoid breaking changes for self-hosting users. We've discussed adding CalVer and a changelog, and I feel like it is not too much to expect self-hosting users to read a changelog when they upgrade and to expect to make adjustments, and for things not to work at all if they haven't followed the instructions. (I found #3558, though I feel like there have been other conversations about this.)

My alternative proposal would be to fail loudly with an error and refusing to start up when .env is present.

That said, I'm happy for this to move forward in any form. So if yous feel like this should be backward-compatible I'm fine with that. We obviously don't have CalVers or a changelog yet (which is sort of a bigger / different kind of job) and I'm happy for this to progress in any form.

[chris48s]

We talked about this in the ops meeting. Consensus is we can skip a formal deprecation period, but when we drop the .env feature, we should detect if a .env file is present. If it is, log an error and link to docs on how to migrate to yaml config or set env vars at run time to help users when they upgrade. We shouldn't just silently boot the server with no config.

[PyvesB]

Following merger of #5864, we've officially dropped support for .env files. The Shields service will log an error and abort start up if such a file is detected.

If you're hosting your own Shields instance, you'll either have to:

• migrate to good old environment variables.
• specify your configuration inside a config/local.yml file.

Please refer to our documentation for more information.