Systematize `nix build`, `nix shell`, `nix develop`, etc (tracking issue)
Is your feature request related to a problem? Please describe.
As discussed in the meeting of 2024-04-15, we propose a new, more systematic naming scheme for these commands, so that they fit into the noun-verb format. Aliases for the current "short commands" will be kept. The purpose of the scheme is to make it so that by following the aliases, the other, less used functionality becomes more easily discoverable.
Describe the solution
Add plumbing commands, and turn the short commands such as nix run into aliases that point to the right place in this noun-verb command hierarchy:
-
nix dev: behaviors that use anix develop-like interpretation of installables, or (later) #7501- [ ]
nix dev print-env:nix print-dev-env(rename+alias) - [ ]
nix dev shell:nix develop(rename+alias) - [ ]
nix dev run:nix develop -c(rename+alias) - [ ]
nix dev script: scoped out for now (could print a script suitable for$SHELL; depends on #7501)
- [ ]
-
nix env: commands that modify the environment- [ ]
nix env run: setenv + execvp?- not decided - maybe this should instead just be a flag to
nix run/nix package run?
- not decided - maybe this should instead just be a flag to
- [x]
nix env shell:nix shell, ie setenv + start$SHELL(rename+alias) - [ ] #10508
- [ ]
-
nix package: "normal" use of installable (whatever that means for the verb)- [ ]
nix package build:nix build(rename+alias) - [ ]
nix package run:nix run(rename+alias) - [ ] #10506
- [ ]
nix package edit:nix edit(rename+alias)
- [ ]
-
nix sandbox: issue tbd (@roberth)
Evaluate whether the code (also file layout, test layout) can be improved after the renames.
Describe alternatives you've considered
There's a long thread, #4715, but note that it's mostly about one or two command; it rarely discusses a naming system.
Additional context
This is somewhat based on https://github.com/NixOS/nix/issues/4715#issuecomment-917069357, but with new insights and team discussion.
Priorities
Add :+1: to issues you find important.
OT: Perhaps nix profile run could be added, to assemble a temporary profile and run a command with it.
Similarly nix profile shell. We'd have to decide whether those transient profiles are mutable. It seems feasible, and we could set something like a NIX_PROFILE environment variable (also used by nix-env; compatible??), so that nested nix profile mutation calls operate on that profile.
Well , I would like to help in this issue, I am first time contributing here and would appreciate some help.
No "idea approved" label yet
But that doesn't have to be a problem and I did propose this in a meeting, so it's not entirely crazy.
I'm double checking with the team that this proposal is ok. I'm not 100% sure about the package subcommands.
Development setup
A good place to get started is the page about development in the manual. This includes things like building it, and setting up clangd. We're switching to meson for building right around now, so feedback is extra appreciated. That's also why I'm linking URLs to the development version of the URL despite its odd redirect UX.
Make sure you set up a language server. A lot of the effort picking up a new project is reading and navigating, and an LSP helps a lot with the navigating. A lot of what I do is Ctrl+click or Ctrl+Enter to open things, and then I have a custom keybinding for navigating back. git grep or a "global find" feature do the other 30% of navigation.
First change to pick
When you've run a local build, I think you could start with a rename like nix env run, which would be analogous to https://github.com/NixOS/nix/pull/10807.
The ones that don't say (rename+alias) tend to be more complicated, but I think we can treat nix env run as a (rename+alias) now.
nix dev run:nix develop -c(rename+alias)
I would guess that this is not actually a rename and alias in terms of implementation; only UX-wise. This probably involve some refactoring so that we have two commands invoking the same piece of code.
If you're doing something that creates new behaviors that aren't simply aliases, also read up on testing. We do almost all of our CLI testing in tests/functional, but the manual will tell you more about that.
More info about contributing is also in the manual and in CONTRIBUTING.md.
So like should I wait till the idea is approved right? Meanwhile I can read all the docs and familiarise myself with the environment. I appreciate your help though.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2024-11-27-nix-team-meeting-minutes-198/56691/1
Sorry ,I am kind of busy with my college exams and projects so didnt had much time recently but I would like to start if you okay with it , can you give me an general idea where to start and how.