41–50 of 64 posts
I still don't see why people use .env when direnv is a thing, and more Unixy.
I 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.
Earlier quoted context omitted.
I’ve always liked yaml but I feel the world is moving towards toml. Keen to see more of toml issues to build a fair comparison
It doesn’t help that YAML has footguns. I love it as an editable format, especially compared to JSON, but for library writers, supporting the whole spec (safely) tends to not be possible; Some even go as far as having a “safe load” function that purposefully violates the spec to remove footguns.
Earlier quoted context omitted.
Until the value has a bang or any other special character that ends up being expanded by the shell and wasting half a day finding it!
> Until the value has a bang or any other special character that ends up being expanded by the shell and wasting half a day finding it! Just how large are your env files?
I find the Twelve-Factor App's design to use environment variable for configuration ( https://12factor.net/config ) unintuitive and perhaps a bad design choice. I believe environment variables are bad for the same reasons global variables are bad. Pros listed for env vars include not committing them to the repo and not encouraging grouping them together as environments such as dev, staging or prod. I don't agree that…
Global variables are bad, but environment variables are actually more like dynamic variables: http://www.chriswarbo.net/blog/2021-04-08-env_vars.html
Dynamic scope is useful for things the caller knows better than the implementor, e.g. configuration, credentials, etc.
> Another alternative to consider for both env vars and config files are command line arguments
The two things which distinguish CLI arguments from env vars are:
- Env vars are usually readable from anywhere, whilst CLI args are usually passed around explicitly (more like lexical scope)
- Env vars are inherently key=value pairs, whilst CLI arguments are better suited to checking presence/absence (e.g. 'foo' versus 'foo --force'), parameters which don't need names (e.g. 'foo myFile') and variable-length lists of parameters (e.g. 'foo file1 file2 file3')
Earlier quoted context omitted.
It doesn’t help that YAML has footguns. I love it as an editable format, especially compared to JSON, but for library writers, supporting the whole spec (safely) tends to not be possible; Some even go as far as having a “safe load” function that purposefully violates the spec to remove footguns.
If you use "NO" it gets parsed as norway
TOML 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" } is to write the following toml: certfile = "path/to/cert.pem" keyfile = "path/to/key.pem" [hosts] "example.org" = "localhost:8000" "foo.com" = "localhost:9000" "sub.example.com" = "lo…
the tradeoff is that your most general top-level settings must come before your category-specific settings, which is usually a pretty natural layout anyway.
Earlier quoted context omitted.
Files are written to disk. In a cloud setup that mean possibly leaking credentials when your disk is re-assigned to another tenant. Yes, cloud provider are supposed to properly erase hard drive before reassigning. Can you be 100% sure they do though ? With environment variable in RAM the problem is moot. Committing and/or generating .env in production system is completely missing the point.
If you're worried about that you should be worried about what gets written to memory too. You have little control over where virtual memory ends up actually storing your bits and bytes. Unless you run without swap, but that's just a bad idea overall.
Your argument does not validate the use of easily recoverable .env file. Recovering a .env file is easier than recovering virtual memory.
I still don't see why people use .env when direnv is a thing, and more Unixy.
Isn't direnv a tool for interactive shells (which also relies on current directory)? There are more ways to launch a process than from an interactive shell (standing in a certain directory, even).
It's perfect for development, and reading .envrc outside of interactive shells is just a "source .envrc" away, or use the appropriate plugin (such as Emacs direnv mode)
Earlier quoted context omitted.
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