3 ms·

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

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.

wrenky 2mo ago
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.
stock_toaster 2mo ago
I also used to use direnv (and likewise eschewed .env), but more recently I moved env definitions to mise. Been working out nicely.
paulddraper 2mo ago
Direnv's first stable release was in 2013, .env was 2012 (adopted by Heroku). So no, if anything direnv makes you hip and edgy.
LawnGnome 2mo ago
No, I also use direnv. It does everything I want, nothing I don't, and has been stable for me for years.
PufPufPuf 2mo ago
I use Mise for env. I primarily use it for installing tools and running tasks, having env support is just a cherry on top.
dolni 2mo ago
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.
- cbarrick 2mo ago
  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."
  - dolni 2mo ago
    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!
- strken 2mo ago
  Interestingly, using source would have the same "bug" as TFA mentions. Though the obvious fix is to use single quotes in the .env file.
  - grim_io 2mo ago
    That's not what the agent suggested. The user asked for a fix, and I guess the AI blindly complied.
curun1r 2mo ago
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).
- drdexebtjl 2mo ago
  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.
  - jdxcode 2mo ago
    I'm biased but I think it's silly to think either one is going away anytime soon
  - bmitc 2mo ago
    > mise is trying to do everything It also doesn't work well. And they have no support outside of Discord chat.
    - cheshire_cat 2mo ago
      What problems did you encounter while using mise?
drdexebtjl 2mo ago
A bonus is that with that approach, you actually have real environment variables.
toshinoriyagi 2mo ago
Yup, direnv + Nix. Incredible combo for development.
afiori 2mo ago
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

wrenky 2mo ago

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.

stock_toaster 2mo ago

I also used to use direnv (and likewise eschewed .env), but more recently I moved env definitions to mise. Been working out nicely.

paulddraper 2mo ago

Direnv's first stable release was in 2013, .env was 2012 (adopted by Heroku). So no, if anything direnv makes you hip and edgy.

LawnGnome 2mo ago

No, I also use direnv. It does everything I want, nothing I don't, and has been stable for me for years.

PufPufPuf 2mo ago

I use Mise for env. I primarily use it for installing tools and running tasks, having env support is just a cherry on top.

dolni 2mo ago

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.

cbarrick 2mo ago
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."
- dolni 2mo ago
  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!
strken 2mo ago
Interestingly, using source would have the same "bug" as TFA mentions. Though the obvious fix is to use single quotes in the .env file.
- grim_io 2mo ago
  That's not what the agent suggested. The user asked for a fix, and I guess the AI blindly complied.

curun1r 2mo ago

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).

drdexebtjl 2mo ago
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.
- jdxcode 2mo ago
  I'm biased but I think it's silly to think either one is going away anytime soon
- bmitc 2mo ago
  > mise is trying to do everything It also doesn't work well. And they have no support outside of Discord chat.
  - cheshire_cat 2mo ago
    What problems did you encounter while using mise?

drdexebtjl 2mo ago

A bonus is that with that approach, you actually have real environment variables.

toshinoriyagi 2mo ago

Yup, direnv + Nix. Incredible combo for development.

afiori 2mo ago

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