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

21–30 of 64 posts

Re: Use TOML for `.env` Files?

#21

Post by palotasb »

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 these are always good goals, but if they are, the same can be achieved with config files: don't commit them to the repo, generate them on the fly.

The existence and prevalence of .env files is proof that using environment variables as an alternative has failed. Using Twelve-factor as a reference and .env files at the same time is a bit of a contradiction.

Another alternative to consider for both env vars and config files are command line arguments.

Re: Use TOML for `.env` Files?

#22

Post by mangecoeur »

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

Indeed, the whole point of the 12 factor design is to decouple the app from a single config file. Instead you use whatever method you like to define environment variables and the app should just work. Also helps avoid committing secrets to your git repo.

I use SystemD extensively and it's pretty neat, you just: - Define default Environment variables in your unit file - Customize a service by adding an overrides.conf file in foo.service.d/ folder This makes it easy to define exactly the environment for a service.

.env files are helpful in dev mode to customise machines where I don't want to pollute the system env, but they aren't the 'config format' and it makes sense that they are specific to the OS/shell they need to run in.

Re: Use TOML for `.env` Files?

#24

Post by meitham »

noselasd wrote: post #18
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 :)

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!

Re: Use TOML for `.env` Files?

#25

Post by nickjj »

I will admit, env files can be pretty "interesting" at times.

I've run into so many issues over the years around incompatibilities with how Docker Compose v1, Docker Compose v2 and Kubernetes tools process an .env file.

Often times it's related to having characters like $ in your value. Across many different examples sometimes you need to single quote the values, other times you need to use double quotes. Often times with Kubernetes tools you can't use quotes (certain ways of populating config maps and secrets from an env file have serious issues if you use quotes). Sometimes you need to escape certain characters, etc.. For a long time Docker Compose didn't allow `export MYVAR=coolvalue` because it had a space in it (it does now).

With that said, I can't realistically see dropping them for a config file because Docker Compose lets you use variable interpolation from an env file in a docker-compose.yml file which is awesome for reducing duplication. Having an env file that you can source in a shell script is also very convenient for ancillary commands that go with your project.

Re: Use TOML for `.env` Files?

#26

Post by meitham »

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

Re: Use TOML for `.env` Files?

#27

Post by mschuster91 »

nishs wrote: post #20
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…

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…

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

Re: Use TOML for `.env` Files?

#28

Post by ldng »

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.

Re: Use TOML for `.env` Files?

#29

Post by nishs »

mschuster91 wrote: post #27
nishs wrote: post #20

Earlier quoted context omitted.

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…

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.

Re: Use TOML for `.env` Files?

#30

Post by vegardx »

Or better yet, have sane defaults and just stick to exporting whatever you need to the local environment. If that ends up being tons of variables, chances are something is very wrong somewhere.
Post reply on HN