Skip to content

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

Closed
roberth wants to merge 1 commit intoNixOS:masterfrom
hercules-ci:issue-4254-nix-shell-autocompletion-and-strictDeps
Closed

nix-shell: Add strictDeps-proof --tools, --inputs#4452
roberth wants to merge 1 commit intoNixOS:masterfrom
hercules-ci:issue-4254-nix-shell-autocompletion-and-strictDeps

Conversation

@roberth
Copy link
Copy Markdown
Member

@roberth roberth commented Jan 14, 2021

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.

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.
@edolstra
Copy link
Copy Markdown
Member

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
Copy link
Copy Markdown
Member Author

roberth commented Jan 15, 2021

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
Copy link
Copy Markdown

stale bot commented Jul 14, 2021

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

@stale stale bot added the stale label Jul 14, 2021
@roberth
Copy link
Copy Markdown
Member Author

roberth commented Jul 14, 2021

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 stale bot removed the stale label Jul 14, 2021
@roberth roberth mentioned this pull request Aug 31, 2021
17 tasks
@roberth roberth mentioned this pull request Sep 10, 2021
@stale
Copy link
Copy Markdown

stale bot commented Apr 16, 2022

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

@stale stale bot added the stale label Apr 16, 2022
@roberth
Copy link
Copy Markdown
Member Author

roberth commented Apr 16, 2022

🎶

@stale stale bot removed the stale label Apr 16, 2022
@stale stale bot added the stale label Oct 29, 2022
@Ericson2314 Ericson2314 added the cli The old and/or new command line interface label Mar 11, 2023
@stale stale bot removed the stale label Mar 11, 2023
@fricklerhandwerk
Copy link
Copy Markdown
Contributor

fricklerhandwerk commented Jun 30, 2023

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
Copy link
Copy Markdown

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cli The old and/or new command line interface

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

Bash completion in nix-shell -p (also solving support for strictDeps by default)

5 participants