41–50 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.
env $(cat .env) [program]Earlier quoted context omitted.
That is kinda the purpose of an environment.
I jump around between multiple projects every day. Sticky environment variables carry risk.
Earlier quoted context omitted.
I jump around between multiple projects every day. Sticky environment variables carry risk.
I would suggest using a tool like tmux to partition those projects entirely. Instead of tearing down env and building it back up to switch projects, just re-attach to that tmux session. I treat this stuff as though it’s immutable and try to consciously avoid cross pollination.
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.
What about: env $(cat .env) [program]
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.
It's a shame that running modern software requires carefully packaging a virtual environment and then injecting a bunch of ugly global env vars.
I still think Docker shouldn't exist. Programs should simply bundle their dependencies. Running a program should be as simple as download, unzip, run. No complex hierarchical container management needed.
Alas I am not King.
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".
Earlier quoted context omitted.
I would suggest using a tool like tmux to partition those projects entirely. Instead of tearing down env and building it back up to switch projects, just re-attach to that tmux session. I treat this stuff as though it’s immutable and try to consciously avoid cross pollination.
That’s reasonable, but my point stands: your original proposal is insufficient to be treated as equivalent.
env $(cat .env) my-cmd-wanting-dotenv
ETA: the main difference between `env` and `dotenv` seems to be that `env` gets its arguments from the command line, whereas `dotenv` gets its arguments from a file. I think that's a fair difference, but I might also think that perhaps `env` should expand its offering to include some kind of `-f filename` option so that it can focus on the notion of "a configurable sub-environment for a command" and we can avoid subtle distinctions.
Earlier quoted context omitted.
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".
What happens when, 30 commands later, you execute a command in your shell and didn't remember that message from a day or so ago?