By itself, "nix develop" is somewhat less nice than "nix-shell" was.. except, I kinda think the intended UX is to use direnv. direnv + nix devshells is super neat.
The DX of being able to just have the development dependencies of a project available (but without being stuck inside a container/VM) is neat.
Since the devshells are provided in nix flakes, they're also much easier to refer to compared to shell.nix files.
As a fish shell user, I also like that `nix shell` respects `$SHELL`. It's a nicer UX than "nix-shell -p <whatever> --command 'fish'".
The only thing I miss from nix-shell was the `#!nix-shell`, which would let nix-shell 'interpret' a file.. so you could describe what packages a script file needed to run in the script file itself.
>As a fish shell user, I also like that `nix shell` respects `$SHELL`. It's a nicer UX than "nix-shell -p <whatever> --command 'fish'".
And this would, of course, also help the zsh using author.
In general it's a great idea to uncouple $SHELL as "the user's preferred interactive shell" from "a shell to run some of our scripts with", and you'd be surprised at how many things get this wrong. Many vim plugins, for instance, do!
IMO the absence of a `--pure` flag (the `-i` flag seems not to work in the same way) makes `nix develop` an unsuitable replacement for `nix-shell`. A few SO threads and nixpkgs issues seem to agree, but if I'm misunderstanding I'd love to learn more.
To be clear, nix-shell --pure serves this use case by accident; it basically drops you into the shell with generic-builder.sh sourced and the build environment for a Nix derivation. This is useful for debugging Nix derivations, and if you are using mkShell you can minimize the pollution, but it's not exactly a development environment tailored for the typical software-engineering workflow.
The tool that (ab)uses nix-shell/nix shell to get this right is devshell [1], which creates an activation script (similar to NixOS itself) that provides a real reproducible development env which works with shells other than bash.
Note that this was written against nix 2.4. I'm not sure if it will make a difference for the use-cases outlined, but I recently upgraded to 2.8 from 2.4-2.7 on various machines. I found the whole experience much nicer overall specifically with flakes on a mac.
The DX of being able to just have the development dependencies of a project available (but without being stuck inside a container/VM) is neat.
Since the devshells are provided in nix flakes, they're also much easier to refer to compared to shell.nix files.
As a fish shell user, I also like that `nix shell` respects `$SHELL`. It's a nicer UX than "nix-shell -p <whatever> --command 'fish'".
The only thing I miss from nix-shell was the `#!nix-shell`, which would let nix-shell 'interpret' a file.. so you could describe what packages a script file needed to run in the script file itself.