31–40 of 108 posts
export $(cat .env | xargs) Agree with the premise but this can be achieved with actual Unix concepts no need for anything else. The language runtime dotenv projects are banned in my engineering org.
Would love to hear more about why dotenv is banned at your org though.
export $(cat .env | xargs) Agree with the premise but this can be achieved with actual Unix concepts no need for anything else. The language runtime dotenv projects are banned in my engineering org.
I tend to agree, and we do this a lot actually. But it gets a little more complicated if you have several .env files. Would love to hear more about why dotenv is banned at your org though.
I believe in convention over configuration. Most of our apps have hard-coded config, with a concise/short and finite number of things that can be overridden (like 3-4 parameters, tops). Secrets get injected.
I do subscribe to the idea of the 12 factor app, but there is a line that needs to be drawn between env config which is more dynamic and more persistent config that should be baked in to the release.
I think direnv already does a good job in this space, and it's already available in your package manager. https://direnv.net/
This idea seems to be cloned everywhere now, so something is causing the popularity
Kubernetes / containderd / docker apps are much more convenient to configure through ENV vars, as they easily pass through the sandbox layer (whatever that may be) files are not so easy to make work. Because that's how prod works devs want to be able to recreate prod to run locally, hence the cambrian explosion of tools like this.
Earlier quoted context omitted.
I've used direnv, but I think a nice property of OP's dotenv is that it's explicit: if I want to pass env vars, I run my program under it. If I don't, then I don't. There's no "hidden behavior" for me to forget about and then get surprised by.
As far as I'm aware of, Direnv's behavior is not hidden at all. Whenever you cd into the directory, you get a message listing all the new en var activated. And when you change the .envrc, you get another message saying that direnv has been deactivated. I never had happen to me "oh shoot !! I forgot this env var was activated because I'm in this dir".
From your description, direnv is implicit and noisy, whereas dotenv seems to be (unless you embed it in a script) explicit and quiet.
export $(cat .env | xargs) Agree with the premise but this can be achieved with actual Unix concepts no need for anything else. The language runtime dotenv projects are banned in my engineering org.
export $(cat .env | xargs) Agree with the premise but this can be achieved with actual Unix concepts no need for anything else. The language runtime dotenv projects are banned in my engineering org.
Your example has the downside of making the environment variables sticky, however, so it's not achieving the same thing.
Earlier quoted context omitted.
Your example has the downside of making the environment variables sticky, however, so it's not achieving the same thing.
That is kinda the purpose of an environment.