Load config from dotenv files

[refs]

Goal

Closes owncloud/product#16

We want to be able to load config values from dotenv files.

Usage

No changes from the original functionality. To get this up and running the only thing you need is to write your extension.env file (i.e: accounts.env, file name is conventional) and run your extension.

For local testing I recommend the following setup:

cat > ~/.ocis/accounts.env <<EOF
ACCOUNTS_NAME=ratatatae
EOF

cd into your ocis extensions location and run:

go run cmd/ocis-{extension_name}/main.go server

You should immediately see the logs with the newly loaded values.

How

While Viper has native support for it, it does not merge environment variables onto structs for a whole set of reasons that you can read here.

The way it works is by loading the environment variables on the .env file onto your actual environment, ready to be picked up by Viper.

The library also offers its own parser, which means we can have comments on such files, like so:

# I am a comment and that is OK
SOME_VAR=someval
FOO=BAR # comments at line end are OK too
export BAR=BAZ

Precedence

extract from godotenv's Readme

Existing envs take precendence of envs that are loaded later.

The convention for managing multiple environments (i.e. development, test, production) is to create an env named {YOURAPP}_ENV and load envs in this order:

env := os.Getenv("FOO_ENV")
if "" == env {
env = "development"
}

godotenv.Load(".env." + env + ".local")
if "test" != env {
godotenv.Load(".env.local")
}
godotenv.Load(".env." + env)
godotenv.Load() // The Original .env

If you need to, you can also use godotenv.Overload() to defy this convention and overwrite existing envs instead of only supplanting them. Use with caution.

This DOES NOT modify the way an extension is configured

---

P.S: Props to @tboerger for pointing this wonderful library out 🙌

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[tboerger]

log.Debug().Str("dir", v).Msg("ignoring missing env file")

:P

[micbar]

@tboerger Nice to see you!

[tboerger]

Shouldn't you just replace something like $HOME or ~ with usr? :)

[butonic]

Do I understand correctly that this adds another mechanism to configure an extension by reading the .env files from multiple locations? If we are aiming at https://12factor.net/config can we get rid of toml, json or yaml style config files and stick to one way of configuring the extension?

[refs]

Do I understand correctly that this adds another mechanism to configure an extension by reading the .env files from multiple locations? If we are aiming at 12factor.net/config can we get rid of toml, json or yaml style config files and stick to one way of configuring the extension?

No, this still uses Viper to load config values, it doesn't add a new mechanism per se. The fact that Viper doesn't merge environment variables, and that it is a bug that is hard for them to change, makes clients (of Viper) do this workarounds.

It really doesn't bring anything new to the mix, as the file name conventions still apply, and file location still apply. That said, the way it works is by reading in any of the configured locations for, in this case, an accounts.env file, and exports this values to the environment, then Viper simply reads them.

You could, as you said, set the config type to .env, or .yaml or even .toml but I personally like the flexibility. If we want to lock the config type to X Y or Z I'd be willing to discuss it, and set a convention 💃 :)

p.s: to address your concern, yes the library has an option to read from multiple sources, but it's not in use here.

[tboerger]

Nothing changed, comments are still ignored 🤯

[micbar]

@butonic why not adressing @tboerger s comments?

[micbar]

At least we need to react.