nix-shell: Add strictDeps-proof --tools, --inputs

[roberth]

Unlike -p, which will be phased out, these are future proof with strictDeps in mind.

A more immediate benefit is that --tools is capable of providing shell autocompletions.

Closes #2504, closes #4254

@Ericson2314 perhaps we could duplicate -p arguments in buildInputs and nativeBuildInputs, emulating non-strictDeps. Seems rather crude though. What do you think?

Preserves the odd packages -p behavior also mentioned in #4230 and assumes intent of -p aka --inputs for those packages.

[edolstra]

Not sure whether we should add more features to the (legacy) nix-shell command. Everything we add to it creates technical debt since we have to port those features to the nix command (or not, but that would make migrating to the nix command harder).

[roberth]

I don't think nix-shell can be considered legacy, because we need it for shebangs. If we migrated it to #!/usr/bin/env nix shell we'd run into the issue that only a single argument is widely supported in shebangs. env will receive nix shell as a single argument, which doesn't work. The workaround for that isn't portable.

We seem to have these use cases here

1. entering a stdenv-based shell: nix develop
2. running some commands without installing: nix shell
3. shebangs: nix-shell

I don't think there's a real need for interactively invoked nix-shells based on stdenv (-p/--tools/--inputs) because if what you're doing is complicated enough that you depend on more than $PATH, you should probably write a file for it anyway.

I understand your caution with the legacy options, but in this case I don't think it creates technical debt, because we don't need to support this in the nix command.

Also, if for whatever reason we do want stdenv-based ad-hoc shells in the nix command, it'd be nice to port a complete solution rather than one with known problems.

[stale]

I marked this as stale due to inactivity. → More info

[roberth]

Still valid. Also, since the nix command can't replace nix-shell due to unix shebang legacy, nix command isn't an excuse.

I'll happily rebase this after a preliminary approval from a maintainer. Or improve it after a review.

[stale]

I marked this as stale due to inactivity. → More info

[roberth]

🎶

[fricklerhandwerk]

Triaged in Nix team meeting:

• @Ericson2314: a nixpkgs CLI can solve this without current or new layer violations
  • Nixpkgs has various types of dependencies, but nix-shell has a very naive view of this, and can not practically be kept up to date
    • for example nix-shell is not aware of cross-compilation as it predates Nixpkgs support for that
  • A more robust solution would be having a dedicated nixpkgs CLI and get nix-shell out of the way
    • it would in fact be worth a great project, as it is not blocked on Nix maintainers
• @thufschmitt: don't necessarily think we should have a nixpkgs CLI, but in any case Nix should not have to bother with these issues
  • this also means that we may have to reconsider nix develop

[nixos-discourse]

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

https://discourse.nixos.org/t/2023-06-30-nix-team-meeting-minutes-67/29835/1