Rename 'nix shell'

[edolstra]

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]

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]

nix inate nixpkgs#git

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

[raboof]

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]

Wasn't this already replaced with nix run?

[bjornfor]

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]

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]

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

[MatthewCroughan]

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]

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]

nix insert

nix shove

[das-g]

No, nix run doesn't start a shell

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

[das-g]

• 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]

Suggestion:

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

[SomeoneSerge]

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

[silky]

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

[colemickens]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

Throwing nix path into the mix.

[nixos-discourse]

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

https://discourse.nixos.org/t/help-with-python-flake-build-from-local-source/30140/8

[dezren39]

nix inject

[Raikiri]

I think next time if there's an actual plan to act on a proposal like this, it's worth making a poll with a fixed deadline and an option "leave it as-is", otherwise while entertaining, this bikesheddingfest will drag on for years and nothing can possibly come out of it.

[jzbor]

I think nix with <your-program> would be a good fit.

It reflects nix' behavior pretty intuitively: You just get a shell with the desired program as opposed to a more complicated actual dev shell.

[AleXoundOS]

If nix develop would put me in a sandbox/environment

I few thoughts about **sandbox**.

Nix has been always trying to be transparent, when it comes to dev environments, blurring the boundaries between package environment and user/outer environment to a reasonable flexible level. So that package is able to build inside, while user tools are still available (in contrast to containers). And only truly sandboxing during the nix build.

But I would like to see what a nix sandbox command could do, specifically denoting going into a sandbox.

nix shell does what I expect it to do

Agree. nix shell has some issues though (e.g. #8177), but not the naming, IMHO.

[LunarLambda]

drive-by suggestion: nix shell --dev[elop] or nix devenv

It seems the main issue now isn't so much about nix shell, but rather nix develop, which lies somewhere between nix shell and nix build. I think grouping it with one of the two might be the way to go.

If I were a new user, nix develop would be pretty ambiguous to me, especially since nix already introduces some less common terminology that sounds like it could be related, like instantiate, realize, derive..., while nix shell --dev (or some bikesheddable variant thereof, or even as one user alluded too, nix build --interactive) would be a lot more intuitive.

maybe it's worthwhile to point out prior art: the meson build system has a devenv command which spawns a shell with library and executable paths set up such that one can run and debug stuff directly out of the build directory, without needing to install first.

[Aleksanaa]

maybe it's worthwhile to point out prior art: the meson build system has a devenv command which spawns a shell with library and executable paths set up

nix devshell sounds good indeed, but that name is already taken...

[Qyriad]

I use nix with as the name for a convenience alias for nix shell with some extra arguments, so @jzbor's suggestion makes a lot of sense to me.

[carlthome]

nix environment maybe?

[nixos-discourse]

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

https://discourse.nixos.org/t/2024-04-10-nix-team-meeting-138/43585/1