Devenv and devbox are completely different. Devenv will merely automatically install envars into your env from a plugin (one of which handles nix). If you aren't using devenv you are missing out, irrespective of whether you use nix. Devbox is a direct alternative to Flox.
Edit: all incorrect, I got confused. There are indeed to many of these Nix wrappers.
I think you're referring to direnv as opposed to devenv.sh which does compete in the same space. Numentide was working on one too.
I am using devenv.sh at work, at home I just nix develop (but this doesn't do services, but there was a flake util just announced that adds support for that I need to check out).
Why `nix develop`, not `nix shell` or `nix profile`? Because you're also packaging the final result with nix anyway or something?
> nix develop starts a bash shell that provides an interactive build environment nearly identical to what Nix would use to build installable. Inside this shell, environment variables and shell functions are set up so that you can interactively and incrementally build your package.
I'm not saying it's bad or wrong - it's a long time since I've used nix and it's changed/progressed a lot, and I'm considering it again so just keen to understand.
I am no expert, but yes, it's flakes for my projects. It keeps the build time tooling separate (eg Go compiler, node version,etc) from the main system (so I could for example have different versions for different projects). It also makes it easier for others that might (one day) contribute to my projects to start developing (assuming they're using nix) with the same tooling and versions that I am using.
aiui, nix shell was the non-flake way of doing things and nix develop is for flakes (this is probably a gross over simplification!)
Nix shell is for devshells declared as a top-level in your flake. 99.99% of the time this is identical to the primary package, but sometimes having additional things around is helpful. E.g. I use justfiles for local dev (meaning I have to pull Just in as a dep), but that isn't something used for a real package build.
Nix profile is for activating profiles, which even a seasoned nix user would have little use for directly. It's what underpins home-manager as an example.
I suppose what I'm missing then is why you ever need to switch from nix shell to (your just etc. -less) nix develop environment?
Is it that the latter is for actually building/running the debug build locally, like a `docker compose up --build` for example? i.e. it's the environment the thing you're working on runs in, but you working on it run in nix shell (with just, git, docker compose in that example, your editor, etc.)?
> Is it that the latter is for actually building/running the debug build locally
Yes, I think. `nix-develop` sets up the environment variables and functions required by the build, both on the Nix side and on the side of the application you're trying to build. So you get all the variables that will be in play in the Nix build sandbox, from the bash functions for each phase of the build and Nix-specific env vars to env vars for things like your CMAKE flags or your PYTHONPATH. `nix develop` lets you interactively explore the build exactly the way Nix will do it, so you can test each piece and maybe even try some manual build steps that aren't yet in place for a build that's not entirely working.
`nix shell` is a simpler 'hey, equip my $PATH with these programs, thanks'
Edit: all incorrect, I got confused. There are indeed to many of these Nix wrappers.