> The problem with using Direnv is that despite it being a very useful tool, its setup requires investing time and getting over the Nix ecosystem's learning curve.
I'm a bit confused. Direnv is rather simple, is it not.. ?
1. put env variables into .envrc
2. direnv allow
I don't use nix and I don't think I'm over its learning curve. I don't remember investing any time into it..
I'm in the same boat here. I'm very not over the Nix learning curve, so I'm left to conclude that it's actually not easy for some projects.
Last time I tried to use Nix to build a dev environment, it did not go well. I wound up in a Turing tarpit of dependencies, as my Python program needed natively compiled libraries and other things to even get off the ground. I kept having to pull in more of the Nix environment/OS to achieve functional isolation from the parent Ubuntu OS. I also ran into problems with online docs and advice skewing wildly from what the CLI options required of me (probably a skill issue).
And that's when it struck me. Docker has pretty much raised the bar for the developer experience. It can achieve the same amount of isolation for far fewer keystrokes, in less time, and (with docker-compose) has a sharable configuration for others. At the end of the day, a container is just a well isolated process whether it's a webserver or a user shell. And really, that's what you need if you're trying to solve repeatability and isolation. As a bonus, if your software is going to deploy as a container, you're that much closer to emulating the production environment (read: fewer bugs).
I like the Direnv concept and have nothing against Nix or folks trying to share the NixOS experience with others. But from a DevEx perspective, my expectations are set at "as easy or easier than Docker."
Direnv and Nix are related in the sense that direnv has a `use flake` command that you can put in your .envrc to load the devShell defined in the project's flake.nix file. It's essentially just an automatic entry to the project's Nix-native devShells.
Edit: this is the only thing I use direnv for - I haven't used direnv without touching Nix.
Hey I'm the author of this blog post. Definitely not GPT-generated, when I was exploring direnv, it was at the same time as I was exploring nix, so the two seemed adjacent in my mind. Admittedly, I should have phrased it better and not confused myself and anyone who read the blog post. What I tried to convey in the blog post was that, trying to setup isolated environments with Nix and automated env switching with direnv, requires investing time in learning about those tools. Devbox abstracts the Nix part and `devbox generate direnv` abstracts the direnv part.
I'm a bit confused. Direnv is rather simple, is it not.. ?
1. put env variables into .envrc 2. direnv allow
I don't use nix and I don't think I'm over its learning curve. I don't remember investing any time into it..