Add reloadability to nix develop

[matthewbauer]

This is my attempt to provide reloadability to Nix develop. There are three parts:

• Adds a "reload" bash function to nix develop which execs with the same command nix develop was called with, destroying the old shell.
• Adds a "--print-out-path" option to nix develop which prints the out path of the dev shell and exists.
• Adds a "--auto-reload" option which checks if the shell out path has changed and calls reload if it does (experimental, it does make your shell kinda slow).

[thufschmitt]

That's a pretty cool approach. Not sure that we'd want to integrate it, but it's pretty nice as a poor-man's direnv.

Did you consider using something like eval $(nix print-dev-env {stuff}) for reload? That would require a bit more work (because you'd need to patch the original command-line a bit), and that might be slightly less correct in some corner cases, but that avoids having to re-exec the shell.

[matthewbauer]

Did you consider using something like eval $(nix print-dev-env {stuff}) for reload?

Yeah I wasn't sure if we could repeatedly eval like that. I think we'd have to rework the rc script a little bit so it is idempotent. exec seems to work pretty well for this kind of thing. You get a little bit of cost with having to reload Bash, but it's pretty fast. The slow part of --auto-reload is really calling nix develop.

[thufschmitt]

Yeah I wasn't sure if we could repeatedly eval like that

I don't think there's anything preventing it. That's (very roughly) what direnv does, and it works rather well. The main difference I see compared to re-running a shell is that it won't clear the “Bash environment” (functions, non-exported variables and friends. Not sure whether there's a name for these). But I can't tell whether that's a drawback or an advantage 😛

You get a little bit of cost with having to reload Bash, but it's pretty fast. The slow part of --auto-reload is really calling nix develop.

Yes, I didn't expect it to really be a performance issue. It's more about the annoyance of having a garbled shell history and all that

[roberth]

This won't work well because of the lack of escaping and the possibility that nix develop fails after the exec.

I don't think nix-shell should have been promoted to nix develop, because it wasn't designed for development shells, but rather to emulate the Nix sandbox. If you're debugging a build (which is what nix-shell and by extension nix develop are for), a reloading function seems like a way to mess up the state of the builder shell, more than anything else.

Development shell problems would be better solved in a new command, and that new command, which is rather open ended, would be better solved by making nix develop an alias for nix run .#nix-develop, so that users are free to write the logic they need, rather than trying to shoehorn everything into a command implementation that's known to overreach and have unfixable flaws.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-07-24-nix-team-meeting-minutes-75/31112/1

[thufschmitt]

Discussed during the Nix team meeting.

Bottom-line: It's a cool idea, but shouldn't belong in Nix itself as it's increasing the conceptual complexity quite a bit and we'd rather have the tool concentrate on the basics

[iFreilicht]

@matthewbauer would you be willing to make a separate PR for the addition of --print-out-path? I think that's a useful feature for debugging a development shell, and it would be a shame if it didn't get merged.