[capableweb]

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, then `.env.linux` for linux, `.env.windows` for windows and so on, and on runtime, first read .env, have values from .env.$os overwrite those, and finally have whatever the actual environment has overwrite those.

Again, simple and hard to misunderstand.

[jepler]

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 `''

[capableweb]

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.