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.

asymmetric commented 3 years ago

On the other hand, it requires you to type 3 word commands every time.

@Radvendii yeah, although we could also think about short versions of arguments (like kubernetes does)

Is this a command that primarily has a single use, or primarily defines a set of actions?

I agree, we could have both, similar to podman:

podman rm $container
podman image rm $image

I think the distinction between flags and additional arguments is that a flag should not change the behaviour of the main command, but rather further specify it.

nix-env --dry-run is a good use for a flag, nix-env -i isn't.

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.

@abathur exactly! So maybe what we should do here is figure out if we want/can foresee multiple verbs for a future nix env/nix equip command. The list of sub-commands I posted above was maybe not super-realistic (although I do like the pin sub-command)

roberth commented 3 years ago

@asymmetric

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.

@abathur exactly! So maybe what we should do here is figure out if we want/can foresee multiple verbs for a future nix env/nix equip command. The list of sub-commands I posted above was maybe not super-realistic (although I do like the pin sub-command)

We can foresee multiple verbs, making noun-verb a good choice. subshell, source and run are valid verbs for nix env. nix env pin may be the fourth verb, if we don't add that feature to nix flake init. nix equip could be an alias for any one of those verbs, so I find it too ambiguous.

barryfm commented 3 years ago

Maybe "nix setup"

abathur commented 3 years ago

nix playground

considerate commented 3 years ago

Suggestion: nix env enter

This would enter the environment with the listed packages. I’m not sure what additional commands nix env would take so maybe opting for something shorter is good since it’s such a common command to use.

However, I’m not convinced that renaming nix shell is warranted.

gytis-ivaskevicius commented 3 years ago

Alright, guys, this is my attempt to get some sort of proper poll going: https://docs.google.com/spreadsheets/d/1_5pHP90UjJbfI3Pvr11xKgwjdkM3uRnzJCzuqK88_q4/edit?usp=sharing

kanashimia commented 2 years ago

I'm not convinced that making such often used commands as nix shell and nix run longer would really benefit UX, for me it would make it much much worse. Adding aliases to such commands breaks autocompletion of flake outputs (at least in bash), which is like the most important feature ever.

shell, develop, run are indeed related commands, and it makes sense for them to be under one umbrella like nix env, but i'm not sure.

Out of proposals i would either choose nix env (without subcommands), as it makes just as much sense as nix shell, short, and is somewhat similar to virtual env that people use for python, or just keep nix shell.

asymmetric commented 2 years ago

@kanashimia is there a way in Bash to get Fish-like abbreviations? (meaning, as soon as you type the abbreviation, it expands into the full command, and then you can autocomplete).

I understand the concern. I'm lucky that I use Fish already and don't have to worry about it, but Bash is like inifinitely more popular, so we should keep brevity in mind too when designing a more ergonomic CLI experience.

asymmetric commented 2 years ago

@hlissner sorry to drag you in here, but as someone who has designed their own nix-env interface (as well as Doom's CLI), do you have any opinions about this?

roberth commented 2 years ago

@kanashimia

Adding aliases to such commands breaks autocompletion

I was thinking of the alias as one implemented in the nix command itself. That's an important distinction. Besides solving your problem, it also keeps the UX consistent across configurations. Presenting the shortcut as such in --help and the man page should help users understand how the commands relate.

kanashimia commented 2 years ago

is there a way in Bash to get Fish-like abbreviations?

@asymmetric i don't know a way for bash, but there is some plugin for zsh. zsh also has option to complete aliases, so no problems there. fish abbreviations have some limitations too, as they only work at the beginning of the line, meaning that you can't expand them after sudo or after &&, as far as i remember.

@roberth yeah i was thinking about this too, something like predefined aliases zfs recieve -> zfs recv, or even custom aliases like in git, albeit that rather sounds like a big hammer approach.

ymatsiuk commented 2 years ago

I'm looking at the description of nix shell and nix exec (like docker|kubectl exec) pops up in my mind.

davidak commented 2 years ago

nix shell states precisely what it does. it starts a shell. you don't have to look up what it does in the manual. maybe look what parameters there are with -h

so i think that is best from enduser UX perspective.

nixinator commented 2 years ago

so we have come full circle, from nix shell -> 64 comments & idea's right back to -> nix shell.....

now that's recursion. :-) LOL.

gytis-ivaskevicius commented 2 years ago

Welp, according to the little poll that I made - nix shell takes up a second place. https://docs.google.com/spreadsheets/d/1_5pHP90UjJbfI3Pvr11xKgwjdkM3uRnzJCzuqK88_q4/edit#gid=0 (Assuming nobody cheated)

nixinator commented 2 years ago

i dont think anyone has cheated, the security of the block chain distributed consensus protocol within the google sheet you have implemented , is incredible...., blimey 'nix inate' , is winning... by a clear margin.

However, after experiencing your discord server and your little band of habbo hotel raiders, i'm not so sure. ;-)

abathur commented 2 years ago

nix shell states precisely what it does. it starts a shell. you don't have to look up what it does in the manual.

It isn't in a vacuum, though. As Eelco said:

... the name nix shell is confusing since there are also development shells (created by nix develop), which this isn't ...

I still think names like "nix shell" and "nix env" risk years of additional frustration with the ecosystem's ~documentation. Because most search engines roughly ignore punctuation, searches for "nix-shell" and "nix shell" will return very similar piles of mixed results (w/ old results benefitting from more time to accrue reputation). "nix shell" has existed for a while and if references to it are correlated with those for "nix develop", literal references to nix shell may already make up ~15-25% of the hits--but note how "nix-shell" still dominates these result pages: google, github, ddg

That said, we might be able to fold nix shell and nix develop into the nix [noun] <verb> form. The results would be mixed, but a bare invocation of nix shell could nudge newer/confused users in the right direction. Something like:

nix shell develop ...
nix shell use ...

We could largely dodge the existing search results ("nix sh", "nix sh develop", "nix sh use"), by shortening the noun:

nix sh develop ...
nix sh use ...

But I'm not sure. IDK if new users will know that's a shell. I don't know if people will assume it's a POSIX sh.

MatthewCroughan commented 2 years ago

@abathur More sub commands would be the death of Nix usability. I do not support this. I actively oppose this idea after working for a company that cleverly implemented [noun] <verb> form in their CLI tool. It was the worst decision we ever made, not one customer could use the tool after this change, it baffled most. The need for support and hand-holding increased dramatically.

abathur commented 2 years ago

Sigh. I don't disagree with you. I'm just following Nix's own CLI docs, and trying to keep us from stepping on the doc/search rake yet again.

Anyways. I'm unsubbing this thread.

nixinator commented 2 years ago

@abathur thanks for the search engines research, it's interesting how the search algorithm works , and basically how it processes "the same" & "the-same" are classified as the same thing.. and you can't actually force it AFAICS , because the index/data probably doesn't actually exist...

"nix inate" only returns 3 hits... ;-)...

Anything that avoids docker noun verb , is a good thing, i'm configuring my OS, not playing Zork 3

naming things in computer science is hard, as well as cache expiry! making cash is even harder.

MatthewCroughan commented 2 years ago

@abathur Yeah, thanks a lot for the research. I think nix shell and nix-shell coinciding in search results is a good thing. Because the difference between nix-shell and nix shell is essentially semantic. Practically, people will be using it the same way, and that is good UX.

das-g commented 2 years ago

the difference between nix-shell and nix shell is essentially semantic.

Do you mean "syntactic" (i.e., difference in form), @MatthewCroughan? If there's a large semantic difference (i.e., difference in meaning), the names better be more different.

MatthewCroughan commented 2 years ago

@das-g I mean that the reason people will be using nix shell is likely to be exactly the same reason they want to use nix-shell, the end user is likely to not care about any of the differences. Unless you can give some reasons that an end-user should care about.

Imagine I am a simple minded developer; why is it a bad idea to assume nix-shell and nix shell are the same?

tejing1 commented 2 years ago

Imagine I am a simple minded developer; why is it a bad idea to assume nix-shell and nix shell are the same?

primarily because nix shell is actually the same as nix-shell -p and nix develop is the same as nix-shell

MatthewCroughan commented 2 years ago

@tejing1 That makes complete sense. nix develop is well named in that case, it is descriptive. nix-shell -p is almost a default alias, it's what people do by muscle-memory and by default. Whenever anyone tells you to use nix-shell it's always with -p.

You almost never see anybody instructing people to use nix-shell alone without -p. So, in my mind at least, nix-shell -p is synonymous with asking someone to "enter a nix shell".

tejing1 commented 2 years ago

I tend to agree. The nix-shell -p use case is probably the primary one for most nix users, so I'm good with letting it keep the similar name nix shell. No need to change anything.

Radvendii commented 2 years ago

This is true for casual users, and somewhat for developers, but not as much. It's a common pattern to have a shell.nix file at the root of a directory, and run nix-shell in order to hack on the project.

Personally I don't mind nix shell, but I also already know what the command does. I do think the shift tripped me up at first, but it didn't take me that long to figure out what was going on either.

tomberek commented 2 years ago

Cross-post from #5189:

Can we add "multiple installables" support to nix develop? Then nix develop is always the one that brings in stdenv/shellHooks. This would create three distinct tools that can hopefully be clearly explained:

1) nix run - only runs an executable, no changes to env vars, multiple installables makes no sense 2) nix shell - only adds things to PATH, multiple installables means to add them all to the PATH 3) nix develop - add things to PATH and run shell hooks. multiple installables means to do a "buildEnv/mkShell" composition.

This idea is less about the specific names, but about the three tiers of tooling. As you go down you get access to more functionality, but also requiring more user understanding.

fluffynukeit commented 2 years ago

@tomberek I talk a bit about shellHooks in #3524. I'm a user who has tried nix off and on for 10+ years. With the new CLI and flakes incoming, I've been motivated to try it out again and have made the most progress from any attempt so far. So I'm coming at this from the perspective of someone who is not an expert in nix or nixpkgs but has reasonable familiarity.

In short, I find it very confusing that something called nix shell would not (and presently does not) run shellHooks. According to the man pages, my understanding is that nix-shell and nix-shell -p both run shellHooks. Therefore, I think nix develop and nix shell should both run shellHooks.

There are a lot of naming decisions between nix and nixpkgs that have sort of cross polluted what expectations are. If I were a new user, coming at this with completely fresh eyes, these would be my minimal assumptions.

Anything named xyzHook should be run when I execute nix xyz command. Right now, nix shell does not run shellHooks (nix develop does, but it does a lot of other stuff as well that I don't want).
Something called nix shell should run against against a mkShell derivation. I understand mkShell is not a buildable target, which is why this doesn't work. But that's a good reason why mkShell is named poorly. It should be named stdenv.mkStage, for instance, to 1) highlight that it is a capability of the stdenv, 2) that it merely sets the stage for a blank stdenv derivation to build, including pulling in the stdenv itself, and 3) that it cannot be used with any command that requires a buildable target.
I think it's ok for nixpkgs to be an implicit installable source when specifying a package, but otherwise I think both nixpkgs and stdenv should have no special treatment from the nix tooling. Every nix command should be fully functional even if I don't use stdenv or nixpkgs at all. So I don't like @tomberek's suggestion of letting nix develop run buildEnv or mkShell; if that's truly what is desired, then those functions should be extricated from nixpkgs and put in the nix tool.

roberth commented 2 years ago

@tomberek Extending an existing derivation with more installables is not simple, but can be done. As a rule of thumb, if they're commands to be invoked in the subshell, they should be added to nativeBuildInputs. If they're components to be included/linked/etc in an impure build they go in buildInputs; see #4452. Other roles may be desirable too. I'd like for Nix to defer this logic to Nixpkgs as much as possible, perhaps an indirection in lib? So when you invoke

nix develop --add-tool pandoc --add-component flask --add-installable depsTargetTarget installable3

nix calls

nixpkgs.lib.extendDerivationForShell drv { tools = [ pandoc ]; components = [ flask ]; depsTargetTarget = [ installable3 ]; }

which Nixpkgs can then evaluate to

drv.overrideAttrs (o: { nativeBuildInputs = o.nativeBuildInputs ++ [ pandoc ]; buildInputs = o.buildInputs ++ [ flask ]; depsTargetTarget = o.depsTargetTarget ++ [ installable3 ]; })

This frees Nixpkgs to evolve its packaging interface.

three distinct tools

I think we should consider two axes of mostly-orthogonal aspects

By which means; a noun command group:

without modifying env
modifying env in a simple way (nix shell as currently exists)
using stdenv
- from a script (UPDATE: script -> derivation? Or did I mean a script to source into a shell, hinting at the implementation?)
- from a script and extra installables (extendDerivationForShell or similar)
- from installables only
merging shells with mkShell (bad idea?)
connect to a shell in the real sandbox except with output store paths that are never persisted to the store (for purity, security)

What to do with the means, a verb subordinate to the noun:

exec the command after -- without any parsing nonsense, ideal for shell style "higher order" commands
run a sh script from the command line, like nix-shell --run; not a big fan of that
run an interactive shell
print a script to source into an existing shell
run a shebang script (can probably reuse logic from the first verb)

Almost all combinations make sense. Only a couple out of the ~25 main combinations aren't useful.

UPDATE: enumerating most combinations and naming things. The naming can possibly be improved. I hope this limits the choice of words by adding the constraints that these should all have distinct meaning.

nix run <drv> <args...>: just nix build and execv.
nix env run <drvs...> -- <cmd> <args...>: build, add to PATH, execve. This could look at passthru attrs to set more than just PATH, but does not rely on stdenv.
nix derivation run <pkg> -- <cmd> <args...>: like nix-shell --run, but with execve-like semantics
nix derivation run --merge-function xyz <drvs...> -- <cmd> <args...>: again, not sure if merging shells is a good idea
nix sandbox run <drv> -- <cmd> <args...>: run a command in a temporary Nix sandbox. <cmd> and <args> replace the derivation builder and args. Not sure if this is the right thing to do.
I'm skipping the "run a sh script", because I don't think we really need it. It's like nix $noun run -- /bin/sh -c $1
interactive shell plus don't modify env is not a useful combination
nix env shell: the current nix shell
nix derivation shell: nix-shell ./shell.nix
nix sandbox shell: like nix sandbox run <drv> -- bash -i
print a script to source into an existing shell doesn't make much sense when the environment isn't modified
source <(nix env script <drv>): nix prints environment variable exports, sensitive to $SHELL if need be
source <(nix derivation script <drv>): nix prints environment variable exports, sensitive to $SHELL if need be
nix sandbox script <drv>: print the exact environment that the sandbox would have. Mostly for debugging.
#!/usr/bin/env nix followed by #!nix run <drv>: exec the provided drv as the interpreter
#!/usr/bin/env nix followed by #!nix env run <drvs...> -- <cmd> <args...>: similar; use <cmd> <args...> as interpreter
#!/usr/bin/env nix followed by #!nix derivation run <drv> -- <cmd> <args...>: similar

Not quite 25 (in fact 14 ones worth enumerating, does that count as "most"? :) ), but I hope this gives some insight into how the larger domain, not just nix shell can be organized into noun-verb commands. Maybe some combinations I didn't enumerate are still worth implementing. What I didn't model is the exact ways in which you could use stdenv. This may be an area where we want to use flags instead, to modify the behavior, although I'm not sure.

from a derivation
from a derivation and extra installables (extendDerivationForShell or similar)
from installables only

roberth commented 2 years ago

@fluffynukeit

Every nix command should be fully functional even if I don't use stdenv or nixpkgs at all.

A stdenv based shell is quite useful, so it makes sense to compromise. For one, we could make Nix depend not on stdenv but a flake with a function in its lib, while also providing hardcoded alternatives like the current nix shell.

The more logic we can move outside of Nix, the more agile the system is. For instance, nix shell still does not support shell completions for the installables, while this was easy to solve in Nixpkgs for shell.nix based shells. nix-shell -p is also still waiting for maintainer attention #4254. Even if this is solved, other features such as python package support are just not feasible to hardcode in the Nix commands.

fluffynukeit commented 2 years ago

@roberth I think my suggestion was unclear. I think you should still be able to use nix shell on a stdenv.mkDerivation and get $stdenv/setup sourced. But, instead of being a hard-coded feature of the tooling, it should be a feature provided by stdenv. It doesn't make sense to me that $stdenv gets special treatment in the tooling here, and here with here. It's the stdenv of nixpkgs, not nix. I believe it could be implemented without special treatment by leveraging the shellHook feature, which is available to any derivation and not just stdenv ones. It would implicitly provide a shellHook step that sources setup but doesn't run genericBuild. Edit: honestly this is how I thought stdenv worked with nix-shell before I looked into it.

nixos-discourse commented 2 years ago

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

https://discourse.nixos.org/t/tweag-nix-dev-update-17/15037/1

figsoda commented 2 years ago

i like both nix shell and nix with

abathur commented 2 years ago

Not keeping up with this anymore, but saw this ~fresh context from a newer user on discourse https://discourse.nixos.org/t/difference-between-nix-shell-and-nix-run/2951/14

nixos-discourse commented 2 years ago

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

https://discourse.nixos.org/t/difference-between-nix-shell-and-nix-run/2951/18

justbhoot commented 2 years ago

Not keeping up with this anymore, but saw this ~fresh context from a newer user on discourse https://discourse.nixos.org/t/difference-between-nix-shell-and-nix-run/2951/14

The current terminology is definitely confusing.

https://discourse.nixos.org/t/difference-between-nix-shell-and-nix-run/2951/18?u=jayesh.bhoot and https://nixos.wiki/wiki/Flakes#Output_schema, combined, gives a lot of clarity.

nixinator commented 2 years ago

so, after seeing the debate run and run and run, you know there is only one option left.

nix inate , is the only solution.

I will merge the PR in master this week.

notifications on this thread have been...DISABLED.

HASTA LA VISTA ...BABY!

das-g commented 2 years ago

nix inate , is the only solution.

Alright, I feel dumb now. :facepalm: I've only now noticed that nix inate is ...

(click to reveal spoiler)

... a reference to @nixinator's username. :upside_downface: (Which in turn, and I've been aware of that since I've seen it, is a reference to the Terminator(s) of [the thusly named movies / franchise](https://en.wikipedia.org/wiki/Terminator(franchise)).)

Is it a serious proposal anyway or were you trolling us bike-shedders (or both)? :thinking:

nixinator commented 2 years ago

You'll find out in the year 2029, when nix.net sends me back from the future.

nix inate, you would definitely have to google it and would do wonders for my (sometimes overly inflated) ego.

nrdxp commented 2 years ago

what about borrowing from git: nix pull? (since we are "pulling" packages into a shell?

gytis-ivaskevicius commented 2 years ago

I am all for democracy but if we ever want to close this issue we need a tyrant. @edolstra will you please do the honors and single-handily pick one of the suggestions from this thread?

Here is a list of solid picks from my point of view:

nix shell nixpkgs#bash
nix with nixpkgs#bash
nix use nixpkgs#bash
nix pull nixpkgs#bash

And in reference to this issue: https://github.com/NixOS/nix/issues/3862 This command should set NIX_<keyword>_PACKAGES env variable which would contain a list of packages used in that particular shell. Something along the lines of: export NIX_WITH_PACKAGES="nixpkgs#bash nixpkgs#vim nixpkgs#xyz" (Yet again, this is another opinionated suggestion of mines)

asdf8dfafjk commented 2 years ago

@nixinator Can you please stop mocking a serious topic? UI is an important part of software, there's a reason why Linux, despite being arguably better than Windows has 1% market share and Windows has 90.

You might not realize it but your posts are offensive.

nixinator commented 2 years ago

The nixinator never jokes. I'm deadly serious. If i cause you offense thats not my intention. A bit of light heartedness and satire is never a bad thing. Maybe the reason linux hasn't got anywhere, is people like yourself who get offended easily.

what exactly do your find offensive, i didn't seen in the community guidelines anything about satire. Do you want to cancel humor. I make my living now from nix and it pays my bills and puts food on my table.

So please give me a heads up of exactly why your offended, because in this day and age, just writing hello can be deemed offensive. If we can't have a good laugh at ourselves, then we take ourselves too seriously, then perhaps that needs to be addressed.

nix inate is a great solution, and i think a lot of people who use windows would agree with me.

nixinator commented 2 years ago

anyway on a more serious note, i have no idea what to call it, nix construct, is the best i've been able to rack my head around.

nix husk, which is probably the only other word for a 'shell' i know.

lucasew commented 2 years ago

nix bring maybe, a stack like analogy is not that useful because you can pop shells using Ctrl+d

jeetelongname commented 2 years ago

for whatever its worth I like use or pull they both make semantic sense (to me anyway) and are ergonomic keywords.

I am leaning more towards use as nix use PACKAGE makes more grammatical sense compared to nix pull PACKAGE but both work perfectly fine

Ericson2314 commented 2 years ago

@edolstra removed this from the nix-2.4 milestone 1 hour ago

Yes the command line is staying unstable so we don't need to figure this out :+1:.

Ericson2314 commented 2 years ago

Back to bikeshedding :)

I do like nix use, I think vaguenes is fine because repeated use reinforces the meaning. People will right blog posts "just nix use the things you need to use in that moment, what could be more simple?!" and it will take on a life of it's own.

nix extend-env
nix scratch-env

I like nix push, except how would nix pop exit the current shell? Unless we can make that go (in a non-hacky way) then we better stay away from any names begging for duals like that :/.

Agreed nix shell has to go because nix-shell will make it too confusing to existing users.

bobvanderlinden commented 2 years ago

Just wanted to mention here that guix migrated from guix environment to guix shell. It changes the semantics a bit as well. I must say that I like their new shell command. It makes sense and seems flexible. It allows combining dev environments with other 'adhoc' packages.

Blog post: https://guix.gnu.org/blog/2021/from-guix-environment-to-guix-shell/

NixOS / nix

Rename 'nix shell' #4715