> But migrating away from .env starts with reading it correctly.
We had a system that mediated all access to the static config through an in-house library. Because nobody touched the environment-specific data directly, it was a convenient spot to layer on reloadable configuration from a Raft source, and fold in environment-specific secrets coming through an old 12 Factor solution, although we could have also integrated some other secrets management as well.
Or, left it as a separate API. That tends to work for tired and distracted people well. Having security related stuff use a unique code pattern to access it does, I find, help keep people from treating it all the same way they treat other data, which is to throw it around profligately and occasionally write it to the logs. The moral equivalent to the guard over the missile launch switch versus the machine gun trigger. One of those has much more forgiving failure modes than the other.
It's the same problem 'capability' based systems frequently run into - capabilities end up meaning that if you can see something you're entitled to use it. And when your coworkers add new features to the system, you end up accidentally being able to see things you shouldn't be able to see.
Java for instance ran into this rather frequently with theirs. Someone would add an object to the global state and not notice that some peer added a reference to a reference to that object with proprietary data the client code wasn't meant to have at all. Information wants to be 'free'.
I am an old man yelling at cloud, but why is a library that does something this simple something that needs maintenance? Like if your jaw is dropping because an environment variable parser hasn't seen commits since 2023 ... ... How old is /usr/bin/env ? Lots of code churn on that one?
What does the ng at the end means? I have seen a few products/projects that added it and no explanation of the meaning.
Can’t you just escape the dollar sign?
If you really believe .env was a mistake (it was), just let it die. You are the ones keeping it alive now.
I love AI development, but I wish product announcements were self-authored.
The beauty of the environment is that it can be manipulated prior to running the program. I don't understand the desire to have runtime .env loaders when that env can just be established before the program is run. Every language can read env without a library. The churn in this space is too high... it's a smell.
I have a shell function for this in my zsh config:
function lenv() {
export $(cat .env | xargs)
}
It doesn't get any more unix than this. I do not allow my team to build software that autoloads environment files using libraries. It's such a mess. That is a concern of the shell.doppler all the way
Am I weird or old-fashioned for relying on direnv over .env? These days my projects use a lot of different tech, and it just feels weird to me to have them all parsing .env files and hoping everything works. Especially with inference provider tokens basically connecting my checking account to the internet.