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