Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use TOML for `.env` Files?

snarky.ca

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Use TOML for `.env` Files?

#31

Post by colejohnson66 »

meitham wrote: post #26
nishs wrote: post #16

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…

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.

Re: Use TOML for `.env` Files?

#32

Post by mschuster91 »

nishs wrote: post #29
mschuster91 wrote: post #27

Earlier quoted context omitted.

Why would you want to require a specific order in the resulting object representation? If you need ordering, use arrays. And if you need to do stuff like content signatures, it makes sense to use some form of normalizer anyway (e.g. alphabetic key order).

There isn't a need for specific ordering of keys in the object representation. But I want to be able to write parts of the toml document in different orders (e.g. "hosts" table before "certfile"; or "hosts" table after "certfile") and still have the same effective object.

Good point, but on the other side a clear visual enforcement between global and section specific stuff makes sense as well.

Apache configs are my personal favourite hate subject here.

Re: Use TOML for `.env` Files?

#33

Post by nicoburns »

meitham wrote: post #26
nishs wrote: post #16

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…

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

I really like the Gura format (https://github.com/gura-conf/gura). Seems to combine the best of yaml, json, and toml for the use case of human created configuration files.

Re: Use TOML for `.env` Files?

#34

Post by vegardx »

ldng wrote: post #28
palotasb wrote: post #21

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…

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.

Re: Use TOML for `.env` Files?

#35

Post by palotasb »

ldng wrote: post #28
palotasb wrote: post #21

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…

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.

"Files are written to disk" is not strictly true. In the use case where the config contains (hopefully short-lived) credentials, one would pass them in a temporary file that usually only lives in RAM (unless /tmp doesn't use tmpfs or the temporary config file is put somewhere else) and of course doesn't get committed to the repo. (I'm not sure if you meant git commit or filesystem commit.)

I sometimes find secrets to be safer inside config files since so many times the environment variables get dumped into logs – hence all the popular CI/CD products have features to try to scrub such secrets from their logs.

I agree about not using .env files in production, I'd not use it at all.

Re: Use TOML for `.env` Files?

#36

Post by jepler »

capableweb wrote: post #9
riffraff wrote: post #4

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 :)

Hear hear! The author claims "There is no standard" but I think the standard is so simple it hasn't been written down. The standard is what you said, KEY="value" and that's it. Simple, easy to parse, fast and compatible with how environment variables are declared in `/etc/environment` since forever. Having different .env files for different OSes is easy as well. You have one `.env` that provides the default values, t…

I wish the 'dotenv' configuration language was so simple that it need not be written down! An off-hand comment (also cited by Brett) says that python-dotenv files "should mostly look like Bash files". Sadly, the vague implication that there's a highly compatible, at-least-ascii-safe subset of dotenv files and bash files is .. very far from the truth.

Here's a line of bash code that sets the variable X to a single-quote character:

    X=''\'''
(lest you think that's an unduly obtuse way to do it, this is what `git rev-parse --sq-quote` does! If not 'best practice' it's surely at least 'practice that's gotta be supported'!)

Here's what python-dotenv gets:

    Python-dotenv could not parse statement starting at line 1
Similarly, when you use python-dotenv to set a key with the value containing only the single quote

    dotenv.set_key('.env', 'X', "'")
the file is not acceptable to bash:

    bash: .env: line 1: unexpected EOF while looking for matching `''

Re: Use TOML for `.env` Files?

#37

Post by lelanthran »

meitham wrote: post #24
noselasd wrote: post #18

Earlier quoted context omitted.

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

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?

Re: Use TOML for `.env` Files?

#38

Post by jrs235 »

black3r wrote: post #12

The 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 (…

>you might just as well use any other file format for your config and call it a config file, not .env

If you name it .env it's much easier to setup source control rules to exclude .env files. If you name them say .config, then you increase the chances of accidentally leaking creds (by checking them into the repo).

Re: Use TOML for `.env` Files?

#39

Post by dahfizz »

I don't understand this article. It complains about parsing an .env file, and that .env files come from 12factor web app methodology?

Environment variables existed long before web apps did. And you are supposed to source the .env file to set the variables in the environment. You don't parse them yourself. You call `getenv()` to get the value for your current environment.

Re: Use TOML for `.env` Files?

#40

Post by whalesalad »

black3r wrote: post #12

The 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 (…

Yes! I’ve really disliked the tendency recently to treat .env files as a sidecar database versus being actual environment variables. Keeping them as KEY=value newline delimited text makes them far more versatile and usable in shell environments.
Post reply on HN