> 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.<p>I'm a bit confused. Direnv is rather simple, is it not.. ?<p>1. put env variables into .envrc
2. direnv allow<p>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..
Direnv is very useful for switching between projects, we have an article:
<a href="https://nixos.asia/en/direnv" rel="nofollow">https://nixos.asia/en/direnv</a><p>But if you are comfortable with Nix you don't need Devbox per se, as you can get by with using Flakes. Here are some examples -- just `git clone` and run `direnv allow` (once), then you are put in the corresponding devShell<p>Haskell: <a href="https://github.com/srid/haskell-template">https://github.com/srid/haskell-template</a><p>Rust: <a href="https://github.com/srid/rust-nix-template">https://github.com/srid/rust-nix-template</a><p>home-manager: <a href="https://github.com/juspay/nix-dev-home">https://github.com/juspay/nix-dev-home</a><p>Dioxus: <a href="https://github.com/srid/dioxus-desktop-template">https://github.com/srid/dioxus-desktop-template</a>
I started messing around with Devbox a few weeks ago and I like it as a faster alternative to toolbox/distrobox containers. I've been adding my environment variables directly into the devbox.json file as normal EXPORT statements. From the article tho, I couldn't grasp what Direnv adds to this. Same Devbox shell, different environment variables per directory?
I try to contribute a lot, which has resulting in me adding .direnv and .envrc to my global gitignores (for other Nix+hm folks[1]). .direnv for obvious reasons, it's a cache, and doesn't frequently show up in project gitignores.<p>I add .envrc to not only avoid committing it to projects that don't use it, but also because it turns out that it's still pretty environment dependent. There's 100 different ways to skin the dependency problem: Nix, pipenv, nvm, rustup, etc. There's no telling which a contributor prefers to use, so .envrc doesn't belong in git IMHO. What could be committed is something like .envrc-flake (which can then be sourced into .envrc).<p>As for needing a flake in the repo, I have found a workaround. `use flake` accepts parameters, including the path to the flake. I have a bunch of shells[2] that I can import with e.g. `use flake ~/Nix#rust`.<p>[1]: <a href="https://codeberg.org/jcdickinson/nix/src/branch/main/home/common/git.nix#L44" rel="nofollow">https://codeberg.org/jcdickinson/nix/src/branch/main/home/co...</a>
[2]: <a href="https://codeberg.org/jcdickinson/nix/src/branch/main/flake.nix#L221" rel="nofollow">https://codeberg.org/jcdickinson/nix/src/branch/main/flake.n...</a>
This is the way. We should make it a standard practice for oss projects that one is able to git clone, direnv allow and build the project.<p>Regardless of the distro or even OS. An easy thing to say, but hard to execute on actual projects with patched versions of cPython and some obscure in-house build tool.
Been using Devbox recently both at work and for personal projects and I can only say good things.
It abstracts away the complexity of nix, defining the dependencies in a simple json with a lock file, the shell starts quite fast and from then on you have everything under your PATH, and it works the same in macOS and Linux.<p>Also, as a benefit, by tracking the JSON and lockfile, the CI can work with the exact same environment. I highly recommend giving it a try.
> despite it being a very useful tool, its setup requires investing time and getting over the Nix ecosystem's learning curve.<p>They mention Nix but I guess they are referring to the use_nix integration built-in to direnv? There is a fairly detailed (but old) comparison in <a href="https://github.com/direnv/direnv/wiki/Nix#some-factors-to-consider">https://github.com/direnv/direnv/wiki/Nix#some-factors-to-co...</a> and in the meantime lorri and nix-direnv are the only ones still maintained. But you aren't limited to Nix when using direnv, for example there is nvm. <a href="https://github.com/direnv/direnv/wiki/Node#using-nvm">https://github.com/direnv/direnv/wiki/Node#using-nvm</a><p>Actually, the post's solution, besides being built on top of direnv, uses Devbox, which itself is built on top of Nix... <a href="https://www.jetify.com/devbox/docs/faq/#how-does-devbox-work" rel="nofollow">https://www.jetify.com/devbox/docs/faq/#how-does-devbox-work</a> So they are saying they are outside the Nix ecosystem when in fact they are in it. It is yet another set of nice scripts on top of Nix.
My experience of Devbox on Linux has been highly disappointing. I gave it a good go, had it running on my main project from February to May.<p>In case you hadn't realised, the very concept of having two sets of binary distributions on one machine, vying for superiority and the correct version of glibc... is fraught.<p>Most of my use was with rails projects, and I can't recommend it.<p>Coupled with an abstraction that tries to save you from Nix, but almost entirely fails, you end up with a bloated hellscape where every time you load your project it will unnecessarily reinstall your packages and several times an hour it will have forgotten curl exists and so you have to manually reinstall curl (not-so-slowly increasing your /nix folder's size), every week or two a new version of devbox completely changes the workarounds you need to do, and don't try to garbage collect nix or it will delete vital files, and you end up scrubbing it all and starting again.<p>In python, it overrode the path so I couldn't get it to reliably use the binaries in the venv. Pip and Python were using packages in different places and I couldn't get them to converge for love nor money.<p>The devbox team were great and really tried to get things working, but in the end I couldn't get it to work with enough stability to properly recommend it to my team, and if I wanted it to half-work for any substantial length of time I had to lock to a version of devbox.<p>Obviously, ymmv, please do give it a try, it's an impressive project. But my view is that it's trying to do something that is very very hard, and for that you need a very clever solution. And this is a very clever solution, with very clever bugs, and so it's not something I'd recommend jumping into with both feet.
Great project which you can also use as your package manager on your system.
This works nice if your developers have a MacBook with an Arm processor and want to have the build process close to what you do in your ci server which might be a Linux amd64
I wrote myself a small tool for dev workspaces in containers: <a href="https://github.com/queil/rooz">https://github.com/queil/rooz</a> - still WIP but I've been using it for quite a while
I created container-shell with a similar goal in mind. It’s super light weight, but does not yet support a package manager. It simply gives you a shell using a specified docker image inside the current directory, isolating both software installs as well as the rest of your filesystem<p><a href="https://github.com/jrz/container-shell">https://github.com/jrz/container-shell</a>
I think this is my biggest pet peeves when working on different projects. Plus port allocation conflict; if you have multiple docker databases or multiple project using the same default port it's not smooth and obviously changing port is not always an option on legacy projects :/
This looks like a huge overkill to solve the problem that's while real, isn't really so difficult to solve with existing tools... Kind of reminds me of Jucero.<p>Also, any solution of this kind will inevitably introduce a number of new problems proportionate to the internal complexity of such solution. I.e. this is just asking for a lot of problems, while offering very little in return.