.env is fine. Don't need another format.
Use TOML for `.env` Files?
11–20 of 64 posts
Re: Use TOML for `.env` Files?
#12The author mentions .env files come from 12factor design, but the 12factor way is just using environment variables directly for configuration.., Environment variables by themselves are language/library agnostic by design and aren't supposed to be cross-platform by design (they're meant to be tied to the "environment" which includes OS)
If you're storing config in a .env file that's read directly by your application (as opposed to sourcing it by your shell or reading it with docker when launching your container), you might just as well use any other file format for your config and call it a config file, not .env.., it'll still be 12factor compatible if the config would still be overridable by environment variables directly...
Re: Use TOML for `.env` Files?
#13My major pain point was that I had big JSON files inside my .env files. We use Cloud Foundry at work and it uses plenty of these for configuration. I wrote a small Rust tool called ‘json_env’[0] to read JSON files and supply them as ENV vars to a program. I’m working on it in my free time and eventually want to also replace direnv with it. TOML and YAML support is also planned. [0] https://github.com/brodo/json_env
But why? Is it not easier to store the JSON as file and have an env variable that points to it?
JSON as env value is utter madness.
Re: Use TOML for `.env` Files?
#14I still don't see why people use .env when direnv is a thing, and more Unixy.
Re: Use TOML for `.env` Files?
#15I always treated .env files as "this is the current set of environment variables", containing just NAME="value" pairs. If there are _different_ sets of variables, they should not be in that file, but in some different place, like the suggested settings.toml. Or perhaps use a bunch of different files in .envs/whatever.env and symlink them. Let's not make everything complicated :)
I have had situations where name="value" will give me ""value"" (I.e double double-quotes) in some languages and others give me just the value.
It's even more confusing if the value contains a space.
It is definitely not consistent.
Re: Use TOML for `.env` Files?
#16TOML is a bad file format for human configuration.
For example, in the following file
[hosts]
"example.org" = "localhost:8000"
"foo.com" = "localhost:9000"
"sub.example.com" = "localhost:9002"
certfile = "path/to/cert.pem"
keyfile = "path/to/key.pem"
TOML has no way to end a [table] on its own; tables continue until EOF or until the next [table].
Re: Use TOML for `.env` Files?
#17TOML is a bad file format for human configuration. For example, in the following file [hosts] "example.org" = "localhost:8000" "foo.com" = "localhost:9000" "sub.example.com" = "localhost:9002" certfile = "path/to/cert.pem" keyfile = "path/to/key.pem" Ordinary human readers would generally think that the hosts table has 3 entries. But TOML considers certfile and keyfile to also be entries in the hosts table. TOML has…
I'm an ordinary human and I disagree. I would not expect a blank line to end the [hosts] table. I find it nice that you can visually separate different categories of entries under a table. I also find it nice that global entries must be at the top of the file – more organized and fewer opportunities for such global entries to get lost.
Re: Use TOML for `.env` Files?
#18I always treated .env files as "this is the current set of environment variables", containing just NAME="value" pairs. If there are _different_ sets of variables, they should not be in that file, but in some different place, like the suggested settings.toml. Or perhaps use a bunch of different files in .envs/whatever.env and symlink them. Let's not make everything complicated :)
And the nice thing about those NAME="value" pairs is you can now source it directly in shells, or read it with some straight forward, usually built in library in many programming languages and supporting tools
Re: Use TOML for `.env` Files?
#19My major pain point was that I had big JSON files inside my .env files. We use Cloud Foundry at work and it uses plenty of these for configuration. I wrote a small Rust tool called ‘json_env’[0] to read JSON files and supply them as ENV vars to a program. I’m working on it in my free time and eventually want to also replace direnv with it. TOML and YAML support is also planned. [0] https://github.com/brodo/json_env
But why? Is it not easier to store the JSON as file and have an env variable that points to it? JSON as env value is utter madness.
Having no config files is part of the 12 factors [0]. All cloud providers I have worked with adhere to this.
[0]: https://12factor.net
Re: Use TOML for `.env` Files?
#20TOML is a bad file format for human configuration. For example, in the following file [hosts] "example.org" = "localhost:8000" "foo.com" = "localhost:9000" "sub.example.com" = "localhost:9002" certfile = "path/to/cert.pem" keyfile = "path/to/key.pem" Ordinary human readers would generally think that the hosts table has 3 entries. But TOML considers certfile and keyfile to also be entries in the hosts table. TOML has…
It's weird that the only way to get the following structure:
{
"hosts": {
"example.org": "localhost:8000",
"foo.com": "localhost:9000",
"sub.example.com": "localhost:9002"
},
"certfile": "path/to/cert.pem",
"keyfile":"path/to/key.pem"
}
certfile = "path/to/cert.pem"
keyfile = "path/to/key.pem"
[hosts]
"example.org" = "localhost:8000"
"foo.com" = "localhost:9000"
"sub.example.com" = "localhost:9002"