[undecisive]

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.

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.

Most of my use was with rails projects, and I can't recommend it.

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.

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.

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.

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.

[KingMob]

We had a similar experience with devenv. It didn't really prevent us from needing to learn nix, and then we had two things to deal with instead of one. We eventually switched back to just nix.

[pxc]

We're pretty happy devenv users at work, despite an annoying bug (with devenv in particular, although it's technically a Nix bug).

One difference that may have been decisive for our success is that when I selected devenv, my goal was not to avoid Nix at all, but rather to choose a nice convention for defining our project-specific Nix environments. I chose devenv because I trust the author's technical leadership (and it also has a decent community of contributors), it is very Nix-forward for this type of tool (most of defining your environment can be done in Nix, and you can even use it just as a Nix library rather than an executable tool (which we do, for one project)), it supports flakes in a first-class way, and it's built on my favorite library for defining flakes (flake-parts) which works via a NixOS-like module system. It also takes care of the direnv/caching optimizations we'd otherwise want to roll ourselves. I also love some of the small conveniences it offers, even when they're pretty easy to do with Nix alonw, like the `scripts` functionality. I also find it pleasantly easy to extend— my team has a couple partially completed upstream contributions on the backlog right now, and they were delightfully easy to get working.

Devenv does admittedly have a lot to it. Each of our projects generally only needs a subset of its functionality, but that breadth of functionality seems justified by the fact that it's not always the same subset that we need. Devenv does currently do some things I don't love, like use a custom Nix build for evaluation and recommend a custom Nixpkgs fork for best compatibility, but why it does those things is clear once you dive in and the future direction in those areas seems sound to me.

All of this is from my perspective as my small team's 'Nix guy'. My manager has some casual Nix experience outside of work, and has had success creating his own devenv environments for some projects I'm not involved in as well. Our other guy is totally Nix naive, but has a solid Unix background. He's never initiated any new work with devenv, but he's used our existing devenv integrations without issue.

I think for a team where everyone is still getting their feet wet with Nix, the approach you guys settled on is quite a sound option. But for teams with more mixed Nix experience levels like mine, maybe devenv can work better. For us, it does a nice job of providing a well-documented, idiomatic, highly compatible Nix library to experienced Nix users on the one hand, while presenting a nice porcelain for the other members of the team on the other.

[zamalek]

I do use Nix and direnv for my work Ubuntu machine. The glibc issue rings true, it was crashing my file manager for quite a long time (I suspect for thumbnail generation). I learned to become better at cli file management ;).

Apart from glibc, I have never had issues with two sets of binaries vying for superiority. Nix binaries take preference with my "vanilla" setup. I think that might be Devbox doing something strange with $PATH?

[undecisive]

Yeah, it was paper cuts - for example, if you don't have git installed inside your devbox, it wouldn't work because of different glibc versions. Which would be fine, but my shell prompt uses git. So there has to be a nix version of git installed for every project for my machine, despite almost no projects technically needing it.

There were a couple of other libraries, can't remember which ones. I remember once having a fun chain of a library that depended on a library that depended on two libraries that in turn depended on glibc, and for some reason the last link of the chain, only one of the libraries was hitting the system libc incorrectly - that was a fun one to debug. I think I ditched that dependency in the end, it was the only solution (and was clearly badly written).

One of my projects used an older version of ruby. In that case, there was a gem to connect to the database, and that gem links to the db client library, but the db is new and the ruby is old and guess what? Two different versions of glibc, both being used within the nix ecosystem.

I worked around a lot of it with LD_LIBRARY_PATH (I think? from memory) which I had to unset for everything in devbox, and used aliases to set it to a backup of that env whenever I found a binary that needed it - and then they tried to fix that, but it just seemed to stop my workarounds from working, so I had to come up with new ones.

But yeah, it was a wild ride. Most of it came back to glibc or environment variables or both, and probably me doing something I really ought not to do (like support old projects). Alas, for me, it wasn't worth the effort - but I sure learned a lot.