Rename 'nix shell' - Githubissues

edolstra commented 3 years ago

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 to pushd / 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.

nixos-discourse commented 3 years ago

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

nixinator commented 3 years ago

nix inate nixpkgs#git

but then again, I'm biased... and a robot from the future.

raboof commented 3 years ago

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.

andir commented 3 years ago

Wasn't this already replaced with nix run?

bjornfor commented 3 years ago

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.

edolstra commented 3 years ago

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.

abathur commented 3 years ago

I recall joking (to myself? in public? I'd have to go look...) that nix snowglobe would be groan-inducingly perfect.

MatthewCroughan commented 3 years ago

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'.

MatthewCroughan commented 3 years ago

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..

rjpcasalino commented 3 years ago

nix insert

nix shove

das-g commented 3 years ago

No, nix run doesn't start a shell

On Nix 2.3.10 without flakes nix run ... does start a shell.

das-g commented 3 years ago

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.

das-g commented 3 years ago

Suggestion:

nix provide nixpkgs#git - tells Nix to provide (i.e., make available) Git. It'll do so in a subshell.

SomeoneSerge commented 3 years ago

One good thing about load is that it might be familiar to some users from module load

silky commented 3 years ago

drive-by-comment: what about nix with ...

colemickens commented 3 years ago

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> ....

zimbatm commented 3 years ago

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

Kha commented 3 years ago

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> ....

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.

abathur commented 3 years ago

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?)

MatthewCroughan commented 3 years ago

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> ....

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.

asymmetric commented 3 years ago

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.

abathur commented 3 years ago

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.

asymmetric commented 3 years ago

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?

abathur commented 3 years ago

... 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.

asymmetric commented 3 years ago

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.

SuperSandro2000 commented 3 years ago

Throwing nix path into the mix.

MatthewCroughan commented 3 years ago

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.

emilazy commented 3 years ago

@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 commented 3 years ago

@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. 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#thing builds thing and then puts its $out on my PATH
nix develop nixpkgs#thing does not build thing. It puts me into a shell where I can run genericBuild and see the $out in my cd

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?

emilazy commented 3 years ago

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.

das-g commented 3 years ago

Throwing nix path into the mix.

Intriguing, but I think nix shell captures the essence from the user's perspective much better: I just want a shell with that software available, whether making it available happens via $PATH or some other ~~magic~~ err, I mean, implementation detail.

Also, nix path could easily be mistaken to refer to any or all of the following:

the directory /nix and paths therein
environment variable $NIX_PATH
nix-path
nix-path
a rust trait that seems to be about paths on UNIX-like ("*nix") systems, completely unrelated to nix

tejing1 commented 3 years ago

I prefer nix shell, however if you must change it, may I suggest nix grab? The concept being that you're temporarily "grabbing" the package in question, to use and then throw away.

gytis-ivaskevicius commented 3 years ago

I like @silky idea with nix with Also, may I suggest nix env since you are creating an environment of some sort using this particular case. Tho it kinda sounds like nix-env

nixinator commented 3 years ago

well some interesting suggestions, i think the main reason, @edolstra is so productive with tools , that he exhausted all the words in the english language. We need a bigger dictionary!!! ;-)

gytis-ivaskevicius commented 3 years ago

Dam, you are right. Its time to start suggesting words from https://www.urbandictionary.com/

roberth commented 3 years ago

nix env Tho it kinda sounds like nix-env

I like env. It is exactly the distinguishing term for this lightweight "deployment method", contrasting it with profiles (combined derivations), NixOS, home-manager, and other tech like docker. Its operating principle is setting environment variables.

Subtle variations can be caught with subcommands.

nix env subshell pkg1 pkg2 -> start subshell source <(nix env source pkg1 pkg2) -> modify current shell environment nix env run pkg1 pkg2 -- command arg1 arg2 -> run command in environment with packages

This is also reasonably close to the cmd noun verb model used by modern CLIs like docker. Reasonably, because I'm not sure if subshell is commonly used as a verb. source is.

It seems that noun-verb has already been agreed on :tada: https://nixos.org/manual/nix/unstable/contributing/cli-guideline.html#naming-the-commands

sounds like nix-env

nix-env is the worst command after nix-channel, so I'd be happy to throw it down the memory hole with vigor.

If we stick to noun-verb, this will be easy enough to distinguish.

Radvendii commented 2 years ago

New ideas:

nix temp (because I'm temporarily installing the package)
nix ad-hoc (guix uses guix environment --ad-hoc, and I think it's actually represents what's going on pretty well)

Of the existing ideas, I like

nix with
nix provide

nixinator commented 2 years ago

nix form (forms an shell environment with packages)
nix form-shell (more descriptive).
nix formation (the shell is taking a predetermined form)
nix shell-formation

https://dictionary.cambridge.org/dictionary/english/form

nix mantle

mantle is what a seashell grows from..... believe it or not.

https://www.gia.edu/gia-news-research/natural-shell-blisters-and-blister-pearls

nix construct
nix construct-shell

just ideas....tough stuff.

abathur commented 2 years ago

I'd forgotten about the CLI guidelines, but if I follow it seems like nix <verb> is preferred unless there will be multiple verbs here. In that light I'll add:

composite (which makes some sense whether you read it as a verb or noun)
draft
compose

liff commented 2 years ago

Inspired by nix provide, more (perhaps silly) alternatives 😄

nix equip
nix lend

MatthewCroughan commented 2 years ago

I dig nix equip! I'd love to be able to say "just nix equip that".

Radvendii commented 2 years ago

Agreed; I like nix equip. I think it does a good job of giving the sense that you're gaining access to something. It also doesn't give me the sense that you're adding it to your permanent collection (that would be your inventory), just the small set of things that you are currently using. It doesn't give me as much of a sense that you're entering a subshell. It might give the sense that you're modifying the current shell. I don't know that that's the critical distinction, though, and it doesn't give me a strong enough impression one way or the other to feel counter-intuitive.

MatthewCroughan commented 2 years ago

nix equip nixpkgs#sword

bew commented 2 years ago

nix equip is nice! Similar to nix with for me (;

asymmetric commented 2 years ago

I like @roberth's suggestions of sticking to the nix <noun> <verb> model, used by tools like Docker and the ip Linux command.

nix env add <pkg>
nix env exit
nix env pin (could e.g. output a flake.nix + flake.lock combo).

This would also make it less likely that we'd have to start adding tons of flags to a hypothetical nix equip command, which is I think part of the goal here. noun+verb is more descriptive and intuitive.

For this reason, I would not go ahead with things like equip or more exotic synonyms.

Radvendii commented 2 years ago

Oh, @abathur mentioned a nix <verb> standard. Were they wrong / misspoke, or are there two competing standards (nix <verb> and nix <noun> <verb>?

abathur commented 2 years ago

Oh, @abathur mentioned a nix <verb> standard. Were they wrong / misspoke, or are there two competing standards (nix <verb> and nix <noun> <verb>?

I have no special knowledge; I'm just citing what @roberth linked: https://nixos.org/manual/nix/unstable/contributing/cli-guideline.html#naming-the-commands

Specifically:

$ nix [<GROUP>] <COMMAND> [<ARGUMENTS>] [<OPTIONS>]
...
GROUP should be a NOUN.
COMMAND should be a VERB.
...

This indicates that the group (noun) is optional, but unfortunately it doesn't try to develop good razors for deciding. Holistically, I get the impression there should be a group/noun when there are multiple verbs, and just a command/verb when there are not.

max-privatevoid commented 2 years ago

For a more magical touch, nix summon

Radvendii commented 2 years ago

@abathur Ah. Group is optional. So both of those standards are valid. nix equip (and some others) fall into the nix <COMMAND> pattern. I think it's a good point that having 3 word commands reduces the number of flags you need. On the other hand, it requires you to type 3 word commands every time.

I would argue the design decision comes down to: Is this a command that primarily has a single use, or primarily defines a set of actions? I don't feel qualified to answer that for the community, but I think of this command as giving me scoped access to some packages. For the additional commands you mention, nix env exit is just C-d or exit, and pin does not seem to be as core functionality as entering the subshell to begin with (and arguably belongs under nix flake).

nixinator commented 2 years ago

For a more magical touch, nix summon

well if your going to go that far, and we all know nix is close to magic (black or white remains to be seen ;-) ) .

nix conjure

raise, devise, bid, collude, bring up, press, beseech, prepare, stir, put forward, call down, arouse, evoke, call forth, machinate, complot, adjure, organize, get up, invoke, cabal, conspire, entreat, organise, conjure up.

nix machinate , nixinators been machinating his machine again.

NixOS / nix

Rename 'nix shell' #4715