Seeing all the love for direnv makes me feel like I'm the only one taking crazy pills.
Direnv breaks referential transparency of the shell. I heavily use my shell history to riff on commandlines I've entered in the past. If direnv is in the mix, my shell pipelines sometimes have to have `cd` in them, often in subshells because that works better for me than pushd/popd.
pyenv/rbenv/asdf do the same thing, but you can have a "global" version pinned and do all your shell-related package installs there, so it doesn't end up being that bad. Though, this still breaks when I happen to be sitting in a directory on my system that has a .python-version file. All of a sudden my "global"ly installed python packages don't work. I greatly prefer tools like pipx / pipsi for this purpose (is there a language-agnostic pipx-alike? or is that nix?) because the shims they install usually work no matter what my shell environment/CWD is.
.... Maybe most of my ire is because my only exposure to direnv is because at least one repo at my day job uses it. For me it's not so much "customize your environment any way you want", it's "oh did you run that command from projectdir/foo instead of projectdir/foo/bar? That doesn't work". Debugging the interactions between people's individual poetry/pipenv/pip/rbenv/direnv/etcetcetc setups and project-based setups is the bane of my work life.
You can just not hook direnv into your shell, and use `direnv exec` kind of like pipx.
Tools like asdf, direnv, nix-shell, etc. just encapsulate the environment and help set up some guarantees. The referential transparency of shells is something that these tools help enforce, if anything.
I agree that frequent jumping between the fragmented environments is pain point in software development these days. That's due to a lack of tooling to support the new workflow, in my opinion. I hope enough people feel this pain that we see some solutions.
Having an expressive shell like https://starship.rs helps keep you oriented as a sort of HUD. Nix is definitely a life-saver, but you can probably roll your own nix-a-likes. Encapsulate all the "global" precious tools, hardening them against changes in the "local" shell environment. Whether through wrapper scripts, containerization, or what have you, the building blocks are there, the "best practices" are still being created.
Although I agree in general, direnv is pretty transparent. For example, you need to approve any change in .envrc and it's pretty verbose. It also solves another big issue for me - I no longer have to install globals like with "npm i -g"and I can use "pip install --user" without trading off convenience and using weird relative bin paths!
Direnv breaks referential transparency of the shell. I heavily use my shell history to riff on commandlines I've entered in the past. If direnv is in the mix, my shell pipelines sometimes have to have `cd` in them, often in subshells because that works better for me than pushd/popd.
pyenv/rbenv/asdf do the same thing, but you can have a "global" version pinned and do all your shell-related package installs there, so it doesn't end up being that bad. Though, this still breaks when I happen to be sitting in a directory on my system that has a .python-version file. All of a sudden my "global"ly installed python packages don't work. I greatly prefer tools like pipx / pipsi for this purpose (is there a language-agnostic pipx-alike? or is that nix?) because the shims they install usually work no matter what my shell environment/CWD is.
.... Maybe most of my ire is because my only exposure to direnv is because at least one repo at my day job uses it. For me it's not so much "customize your environment any way you want", it's "oh did you run that command from projectdir/foo instead of projectdir/foo/bar? That doesn't work". Debugging the interactions between people's individual poetry/pipenv/pip/rbenv/direnv/etcetcetc setups and project-based setups is the bane of my work life.