nix
nix copied to clipboard
NixOS
Rename 'nix shell'
The nix shell command replaces nix-shell -p to provide a shell in which the specified packages are available. However, the name nix shell is confusing since there are also development shells (created by nix develop), which this isn't; and the old nix-shell by default does start a development shell. So we should come up with a better name. Some suggestions have been made:
-
nix load nixpkgs#git- "load" a package into the current shell. This one mainly makes sense in the context of updating the current shell, rather than starting a subshell. -
nix push nixpkgs#git/nix pop- update the current shell to add a package to the environment (similar topushd/popd) -
nix use nixpkgs#git- "use" is probably too ambiguous though. -
nix add nixpkgs#git- probably sounds too permanent. -
nix bonk nixpkgs#git- random name with no connotations that forces people to read the manpage.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/how-to-invoke-nix-shell-p-for-packages-not-in-nixpkgs/12475/6
nix inate nixpkgs#git
but then again, I'm biased... and a robot from the future.
I actually quite like nix shell: it nicely indicates that the command affects the 'current shell', and does not have 'side effects' (using the term loosely). I'm not sure the confusion with development shells is such a problem: it's clear for regular users that nix shell is the one they need, and when developers learn about nix develop they're likely already familiar with nix shell, so that might be smooth enough.
I like push/pop because it makes it clearer you can 'nest' shells, but it's not so clear "what is pushed on what" and where that change is 'visible', so I'm not sure it's a net improvement.
nix enter might be another option, as you're 'entering' an environment with different behavior.
An idea: adding another command level to disambiguate: nix add <where>, i.e. nix add [new-shell|this-shell|user-profile|global-system]
I used add here, but other verbs also work well with the explicit 3rd argument.
Wasn't this already replaced with nix run?
No, nix run doesn't start a shell, it directly runs the specified app or the default program from a package.
nix enter might be another option, as you're 'entering' an environment with different behavior.
Maybe nix enter could be the subshell variant of nix load.
I recall joking (to myself? in public? I'd have to go look...) that nix snowglobe would be groan-inducingly perfect.
nix inate nixpkgs#git
but then again, I'm biased... and a robot from the future.
Either bonk or inate would cause the user to read the manpage. I like both. nix inate just sounds too cool and is my preference.
A custom suggestion of my own would be nix actualize, although nix inate already kind of implies that in the same way - 'bringing something into existence'.
If spelt with two n's, innate is actually a word. It could imply that the shell is the innate behavior/feature of nix, that you can run a nix shell on anything.
It could imply that everything is built from a shell.
Innate - An innate quality or ability is one that you were born with Innatism - A philosophical and epistemological doctrine that holds that the mind is born with ideas/knowledge
nix innate - I love it..
No,
nix rundoesn't start a shell
On Nix 2.3.10 without flakes nix run ... does start a shell.
nix bonk nixpkgs#git- random name with no connotations
You'd be surprised. According to Wiktionary, Merriam-Webster and some other dictionaries, it can mean
- (transitive) to hit or strike [someone or something]
- (transitive) have sex with [someone]
- (intransitive) to experience sudden, severe fatigue during strenuous activity
It might be better to choose something with connotations where we know (most of) the connotations in advance.
Suggestion:
-
nix provide nixpkgs#git- tells Nix to provide (i.e., make available) Git. It'll do so in a subshell.
The only variant of all of these that properly convey "sub-shell", to me, is nix shell.
(to me, ) nix [add,load] etc all look/feel too similar to nix profile add and make me think they're affecting my current environment, rather than what it's actually doing, dropping me into a subshell with specific extra environment added.
I actually like nix shell, whereas I can barely ever remember/figure out the semantics around what nix run does or what cases it's meant for. Nearly every time I try to use it, I have to revert to nix shell <runnable> -c <cmd> ....
Another way to look at this is that the command creates a temporary profile. If that profile was recorded and exposed as an environment variable, it would then become possible to play with it. nix profile add would then use that profile instead. And nix profile save somefile.nix at the env could be used to save the session. That way one doesn't have to enter-exit or create yet another sub-shell to get the missing dependency.
$ nix profile shell nixpkgs#python3
$ pip install
Error: zlib is missing
$ nix profile add zlib
$ pip install
Success
$ nix profile save ./session.nix
Or it could be called nix env in short
I actually like
nix shell, whereas I can barely ever remember/figure out the semantics around whatnix rundoes or what cases it's meant for. Nearly every time I try to use it, I have to revert tonix shell <runnable> -c <cmd> ....
But note that the latter does not spawn a shell, so I sometimes have to extend it to nix shell <runnable> -c bash -c '...'. In that case, the current name can be confusing.
TL;DR: I think a review of the existing search results (in a few engines) should be a heavily-weighted factor here.
The only variant of all of these that properly convey "sub-shell", to me, is
nix shell.
This reminds me of something I've thought for a while.
One contributor to the difficulty of finding your nix-legs is that some ecosystem terms are hard to isolate in search results. I think the main drivers are: overloaded uses of terms/concepts/commands within the ecosystem; unrelated *nix results (especially with generic terms); how a search engine treats space/symbols/punctuation; and how a feature (or the ecosystem) has evolved since a given result was written.
When I first pulled my head out of the sand to figure out the ~vision of the new subcommands, it struck me that re-using nix shell may inflict a lot of this kind of difficulty. (But I assumed the call was made by that point.)
I don't think nix shell is a bad name, but results for both nix-shell and nix shell will continue diluting over time in any search engines that don't exactly match the terms. Unless nix shell retains such strong option/syntax/behavior compatibility with nix-shell that they can share a manpage, I suspect this will be a cruel choice to inflict on people trying to learn Nix.
The affordances split out into a dedicated command named nix shell are one of the ecosystem's big carrots, so I imagine a fair share of new (non-NixOS) Nix users are focused on how to put it to work. Any rename inevitably causes some confusion--but that confusion is going to be easiest to sort out if it is trivial to find relevant, high-quality results.
I think it makes sense to review/reflect on results for any serious candidates here across a few of the most-relevant search engines (general, source code, forums/social, Q&A, ...) before making a final decision. (I'm not really sure when; I assume this can't be meaningfully automated and would need to be somewhat manual/holistic; it's probably best to save the effort for serious candidates?)
The only variant of all of these that properly convey "sub-shell", to me, is
nix shell.(to me, )
nix [add,load]etc all look/feel too similar tonix profile addand make me think they're affecting my current environment, rather than what it's actually doing, dropping me into a subshell with specific extra environment added.I actually like
nix shell, whereas I can barely ever remember/figure out the semantics around whatnix rundoes or what cases it's meant for. Nearly every time I try to use it, I have to revert tonix shell <runnable> -c <cmd> ....
If we're not trying to give this a silly name for fun, then I totally agree. I like nix shell more than any other suggestion. The arguments made about searching for this term in future google are accurate, any other choice will likely lead to confusion.
I agree with sticking to nix shell, it makes the most sense.
the name nix shell is confusing since there are also development shells (created by nix develop), which this isn't;
I don't think this is that confusing. Users who skim through a nix help would look at nix shell and understand it creates a shell.
They would look at nix develop and probably not immediately understand what it does. So maybe we should rename nix develop, rather than nix shell. (EDIT: IIRC develop used to be called devshell?)
the old nix-shell by default does start a development shell.
This was a problem in nix-shell. The 2.4 commands are a clean break with the previous ones, so there's no need to inherit their history of quirks.
the old nix-shell by default does start a development shell.
This was a problem in
nix-shell. The 2.4 commands are a clean break with the previous ones, so there's no need to inherit their history of quirks.
This is obviously true in a technical sense, but I think it's a trap to frame this as a "clean" break when many search engines will yield identical results for "nix shell" and "nix-shell".
Until "nix shell" results entirely displace "nix-shell" ones, nix newbies will have to understand enough about this distinction/history to understand whether they're reading about the right thing or not. It will only be a clean break for insiders.
That’s true. On the other hand, the cost reduces over time, as more and more results mentioning the new command gain precedence.
Or are you suggesting we rename twice, using a placeholder for a while, then switch to nix shell in a couple of years?
... the cost reduces over time ... Or are you suggesting ...
I'm just suggesting ~searchability (across whatever code+general search engines we care about) deserves to be high enough up the criteria list (especially given Nix's existing headwinds here) that the final decision is clear-eyed about the likely (short|long)-term impact on users trying to get their arms around Nix.
Right, I understand your point.
I still think we could reasonably make the choice to go for nix shell, since search engines tend to favor newer pages (and official ones).
Of the other terms, nix env is the only other one that makes as much intuitive sense to me.
Just to explain more of my point of view:
It would be really bad if the following scenario occurred:
- Hmm.. I wonder what this new thing is
- Google for a while and it's still not clear
- Asks in IRC
- Gets a response back saying "It's just a nix-shell"
- Oh! It's just the new cli's idea of a shell, which I'm already familiar with, why did they name it that!?
If we rename from nix shell I believe that scenario is inevitable.
@MatthewCroughan It’s important to remember that it is in fact not the equivalent to nix-shell, even if nix-shell was previously used for similar purposes; the equivalent of nix-shell is nix develop.
@MatthewCroughan It’s important to remember that it is in fact not the equivalent to
nix-shell, even ifnix-shellwas previously used for similar purposes; the equivalent ofnix-shellisnix develop. Is what you said actually true though?
With nix develop I will actually have access to the application's build environment, not its produced result on my PATH like would be true with the shell if I supplied -p like nix-shell -p firefox
-
nix shell nixpkgs#thingbuildsthingand then puts its$outon myPATH -
nix develop nixpkgs#thingdoes not buildthing. It puts me into a shell where I can rungenericBuildand see the$outin mycd
If I ran nix-shell on a .drv I would absolutely see the same result as nix develop, is that why you are comparing it?
Right, the meaningful comparison is to e.g. nix-shell -A firefox '<nixpkgs>'. Note that nix-shell -p firefox still puts you in a build environment: $NIX_BUILD_TOP will be set, it always uses bash, gcc will be in the $PATH, etc.
Reproducing the exact effect of nix-shell -p is difficult with nix develop, which is annoying; nix develop --impure --expr 'with import (builtins.getFlake "nixpkgs") {}; mkShell { nativeBuildInputs = [ firefox ]; }' is, I think, the closest equivalent. But most of the time people just want the nix shell behaviour, anyway, so I agree that in some ways nix shell is a replacement for nix-shell, but my point is that precisely this ambiguity/dual-use nature where people use nix-shell to pull in packages for normal use without realizing they're entering a build environment is what is likely to proliferate more confusion, probably regardless of what the nix(1) subcommand is named.