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

51–60 of 64 posts

Re: Use TOML for `.env` Files?

#51

Post by tough »

colejohnson66 wrote: post #46
tough wrote: post #43

Earlier quoted context omitted.

If you use "NO" it gets parsed as norway

The whole "`NO` is Norway" thing is indeed one of the footguns people love to bring up. However, as someone who is writing the YAML manually, and has a syntax highlighter, these issues don't manifest.

I dunno, this is where I said fuck it and never used it again.

I don't know what kind of mind will that as an OK reserved word for a programming language. but OK..

I guess I'm lucky I didn't need to use yaml for my work.

Re: Use TOML for `.env` Files?

#52

Post by capableweb »

jepler wrote: post #36
capableweb wrote: post #9

Earlier quoted context omitted.

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

Sounds like a problem of python-dotenv rather than a problem with environment variables. Env vars have been around forever, it's has well established syntax at this point, that X tool doesn't handle it properly doesn't mean the format is wrong.

Re: Use TOML for `.env` Files?

#53

Post by andrewflnr »

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…

Global variables are primarily bad when they're mutable. Environment variables are (usually anyway) global constants, which are indispensable.

And generating config files sounds like a pain, probably more complexity than a lot of us really need. Though I don't disagree that it's a little silly to take env files too seriously as a format.

Re: Use TOML for `.env` Files?

#54

Post by nishs »

tough wrote: post #43
colejohnson66 wrote: post #31

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

I thought it was the other way around? i.e. "NO", in a document that intends "NO" to mean "Norway", is parsed as "False".

Re: Use TOML for `.env` Files?

#55

Post by TeMPOraL »

mschuster91 wrote: post #32
nishs wrote: post #29

Earlier quoted context omitted.

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.

The "global" and "section specific" stuff stops being so clear once you need to have subsections. And the "clear visual enforcement" can also lead to forced unreadability, when the ordering forced on you doesn't match the most sensible/readable order for a human reader.

This is repeating the same mistake I see all the lightweight markup formats (Markdown, Org Mode, etc.) do - using implicit terminators for hierarchy nodes. It's a superbly annoying feature of outliner tools (including the one I otherwise love: org mode) that forces you to create extra levels of structure just for the sake of being able to surround subtrees with context.

Re: Use TOML for `.env` Files?

#56

Post by alexisread »

palotasb wrote: post #35
ldng wrote: post #28

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.

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

This is an advantage with sqlite as a config store as well - initial db config file augmented in-memory with secrets, accessible from all major languages, without relying on the vagarities of the filesystem (windows vs Linux tmp mount points) and easy to have multiple switchable configurations depending on environment, test mode (integration tests after deployment etc.) or customer.

Re: Use TOML for `.env` Files?

#57

Post by alexisread »

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.

This is an advantage with sqlite as a config store as well - initial db config file augmented in-memory with secrets, accessible from all major languages, without relying on the vagarities of the filesystem (windows vs Linux tmp mount points) and easy to have multiple switchable configurations depending on environment, test mode (integration tests after deployment etc.) or customer.

Re: Use TOML for `.env` Files?

#58

Post by scbrg »

sph wrote: post #49
scbrg wrote: post #41

Earlier quoted context omitted.

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

Direnv loads the environment variables listed in .envrc in the current shell. On Unix all spawned processes inherit the environment of their parent. 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)

Yes. I'm aware of this. My point is, not everything that starts a process is an interactive shell (or a subprocess of an interactive shell), and even when you do launch things from a shell, you're not necessarily in the directory of the thing you launch. Examples would be automatic builds on code commits, cron jobs or whatever.

So in the end the magic of direnv is only helpful in special circumstances. Outside those circumstances, you'd have to treat its directory local configuration file like an .env file anyway, and a more complicated one at that given that it's likely to contain shell keywords (such as unset) which your parser has to be aware of - so now you're worse off than with regular .env files.

Re: Use TOML for `.env` Files?

#59

Post by alexisread »

ly3xqhl8g9 wrote: post #5
alexisread wrote: post #2

TBH, config is one of those Pandora's boxes - what happens if I want to do an integration test using a dev database and local docker images? what about testing after deployment to prod? Given the myriad of configurations that can exist, including secrets management, static data etc. I would be very tempted to try to build tooling around a sqlite database, storing all your configs including static data, and update it…

One way to solve this is to be able to import into the .env file: import values from local/or/public/private/url ...values When reading the file, the environment variables will be obtained from the URL and populate the environment. This is what I had in mind when designing the import functionality for deon [1]. Being able to import also makes it easy to have a .base, a .production, a .local setup, and combine them ac…

Neat solution, sqlite gives you much more though. What happens with the .env files with inheritance eg. env.linux overridden by env.linux.local? You need one url per permutation, or call them in the correct order, now you have a config for your config.

What about if you require multiple local configurations for eg. testing inside and outside docker?

What if you have several developers working on the same codebase with different settings? What if you have static data that changes with environment? Sqlite can answer all of this, including parsing quotes and handling filepaths in a uniform fashion

Re: Use TOML for `.env` Files?

#60

Post by heywhatupboys »

dahfizz wrote: post #39

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.

It is because the article is just "bad"...

> And then you could take the table idea farther and have a table for a specific [purpose] . You could have a [purpose.test] or [purpose.production], all without having to use separate files where you may accidentally leave out a common setting that every .env file needs to define for your application. (I'm also a fan of less configuration files, not more.)

that is the complete OPPOSITE purpose of .env files!! It is supposed to be such that you never conflict the information, and no simple "flag" sets production vs local environment vs test environment.

Post reply on HN