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.
The concept is fine, but I'm a big fan of doing it with mise instead. It does the exact same thing plus a lot of other things really well. The environment for a project is not just things that get stored in environment variables, it also includes specific versions of tools, common project tasks, git hooks and such. Being able to manage all of that in one place ends up being really useful.
I also really like that for sensitive variables (AWS tokens, prod DB passwords, etc), I can keep those in a dedicated secret store (I use 1Password for personal projects and there are more enterprise focused alternatives for work).
direnv does one thing really well, and it enables a large ecosystem of other components that you can pick and choose to build developer environments. SecretSpec, from the featured article, is one such component which pairs really well with direnv, and has the features you’re describing for secrets.
I think direnv’s approach is the one with more staying power.
Dotenv is definitely something that should not exist.
Direnv is the right way to go if you want a tool for this. Otherwise dotenv's implementation in bash is essentially `set -a; source .env`. Look ma, no custom parser!
Seems really silly to have a library do what two lines of shell can reasonably accomplish.
direnv + nix flakes solved so many problems for me, I have no idea how other people work on multiple projects at the same time without getting mixed up.
Most uses of .env files are for apps or containers imho, so you could just have a .env file in each folder and configure docker compose /node / whatever to pick it up
Comments
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.
The concept is fine, but I'm a big fan of doing it with mise instead. It does the exact same thing plus a lot of other things really well. The environment for a project is not just things that get stored in environment variables, it also includes specific versions of tools, common project tasks, git hooks and such. Being able to manage all of that in one place ends up being really useful.
I also really like that for sensitive variables (AWS tokens, prod DB passwords, etc), I can keep those in a dedicated secret store (I use 1Password for personal projects and there are more enterprise focused alternatives for work).
mise is trying to do everything.
direnv does one thing really well, and it enables a large ecosystem of other components that you can pick and choose to build developer environments. SecretSpec, from the featured article, is one such component which pairs really well with direnv, and has the features you’re describing for secrets.
I think direnv’s approach is the one with more staying power.
I'm biased but I think it's silly to think either one is going away anytime soon
It also doesn't work well. And they have no support outside of Discord chat.
What problems did you encounter while using mise?
Dotenv is definitely something that should not exist.
Direnv is the right way to go if you want a tool for this. Otherwise dotenv's implementation in bash is essentially `set -a; source .env`. Look ma, no custom parser!
Seems really silly to have a library do what two lines of shell can reasonably accomplish.
Interestingly, using source would have the same "bug" as TFA mentions.
Though the obvious fix is to use single quotes in the .env file.
That's not what the agent suggested. The user asked for a fix, and I guess the AI blindly complied.
That shell snippet will expand shell variables in double-quote strings. And apparently the entire reason for this fork is to not do that.
Which is dumb. The canonical spec for .env should just be "whatever POSIX sh does."
Agree, not expanding is dumb.
One of the major benefits of a shell-based approach is your env vars could be generated from the output of a command.
Which can be trivially used to populate secrets from whatever your secret store of choice is.
Now we've also cleanly solved secret distribution for developers with one less dependency!
I also used to use direnv (and likewise eschewed .env), but more recently I moved env definitions to mise. Been working out nicely.
No, I also use direnv. It does everything I want, nothing I don't, and has been stable for me for years.
direnv + nix flakes solved so many problems for me, I have no idea how other people work on multiple projects at the same time without getting mixed up.
Direnv's first stable release was in 2013, .env was 2012 (adopted by Heroku).
So no, if anything direnv makes you hip and edgy.
A bonus is that with that approach, you actually have real environment variables.
Most uses of .env files are for apps or containers imho, so you could just have a .env file in each folder and configure docker compose /node / whatever to pick it up
Yup, direnv + Nix. Incredible combo for development.
I use Mise for env. I primarily use it for installing tools and running tasks, having env support is just a cherry on top.