Open edolstra opened 3 years ago
Drive-by comment: nix pull
sounds like it means to download the package. Which can be part of the implementation of what this does, but doesn't really get at what it does from the right angle. Sure in git
– which isn't necessarily what I mentally compare nix
to – pull
is a fetch
and a merge
, but arguably the more important part here is not the fetch
/download step, and you wouldn't call this nix merge
…
[EDIT:] Just remembered docker pull
which as far as I'm aware is only a download.
Skimming this thread made me think of:
nix ephemeral
.
This sounds like shell in English and conveys the transient nature of temporary environments.
Some thoughts based on my understanding, which is probably quite poor. Please correct me if I am wrong.
nix-shell -p python39Packages.numpy
produces an environment where you can run python
then import numpy
. That is because $PYTHONPATH
and other vars are set, due to setupHook
running like this https://github.com/NixOS/nixpkgs/commit/7a65bb76f1db44f8af6e13d81d13f41d69fb1948#diff-f83144cf7d05c21581cb058d190b2267399eaad77aac7cc6a29c39726b8f2d38
nix shell nixpkgs#python39Packages.numpy
does not produce the same environment. It does not run setupHook
and it does not even give you python
on the path.
I think it might be the case that derivations that rely on setupHook
to provide a useful environment for their closure, to be remade and reconsidered how they would conform to nix shell
, which expects only the closure to be the useful artifact, rather than any of its phases. And that is a lot of work. However I think nix shell
's approach of only providing the closure, rather than any hooks of the derivation is the correct thing to do and can only make Nix easier to understand and consistent from the perspective of newcomers, though this will be harder to understand for people who have already been using Nix for a while.
user: matthew ~
❯ nix-shell -p python39Packages.numpy
user: matthew ~ via ❄️ impure (shell)
❯ python
Python 3.9.6 (default, Jun 28 2021, 08:57:49)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>>
user: matthew ~ via ❄️ impure (shell) took 3s
❯
exit
user: matthew ~ took 7s
❯ nix shell nixpkgs#python39Packages.numpy
user: matthew ~
❯ python
python: command not found
user: matthew ~
❯ nix shell nixpkgs#python39
user: matthew ~
❯ python
Python 3.9.6 (default, Jun 28 2021, 08:57:49)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'numpy'
>>>
nix cook
:smile_cat:
I think the names are fine as they are: "I want to develop
this package" vs. "I want a shell
with these packages available".
The confusion comes from nix-shell
serving two distinct purposes, but this should not constrain what we do going forward. If anything, I expect the confusion from renaming nix shell
now to outweigh the confusion between nix shell
and nix develop
. (Apologies if this has all been said before)
EDIT(after @tejing1 agreed): this doesn't address the fact that shell
is ambiguous, but I don't think we're going to find a less ambiguous name without going for something too long to be convenient.
@ncfavier I agree.
Quick summary of what criteria a replacement name should satisfy, from reading the comments:
Personal opinion:
I prefer nix equip
the best out of all the other proposals, because it hits all four points adequately, and it gives the exact picture of picking up a package before dropping it again.
nix {add,load,insert,shove,temp,ad-hoc,with,bring,lend,cook,form,construct,provide}
fail the ambiguity criteria; nix shell
/ nix env
fail the search engine criteria (as they would continually get confused with nix-shell
or nix-env
); nix {ephemeral,extend-env,scratch-env}
or nix <noun> <verb>
fail the easy-to-type criteria; and nix bonk
or any other "random word" proposal fail the remembrance criteria.
There are some other proposals that pass the criteria too, and these are generally good options, but have a few issues:
nix pull
: As said earlier in the thread, it sounds like it downloads the package, even though downloading the package is actually a side effect of the main function (bringing packages into one's environment). This is problematic because the assumption that it downloads things is dangerous: it's the kind of thing that gets a developer who hasn't read the docs to roll their own caching for a package just because "nix pull
always downloads it."nix push
/ nix pop
: These work, but they introduce stack symbolism which isn't present anywhere else in Nix. Also nix pop
may not be possible to implement.nix use
is probably my second choice, despite being a bit ambiguous."nix-shell" has become the Nix Brand. Maybe even to a greater extent than "nix-build", because newcomers hear and meet "nix-shell" first. Also, it is needed for a wider audience than developers. Losing nix shell naming means a huge loss.
And in my opinion nix shell
is the right name for the legacy nix-shell -p
. It cannot be more precise because it's up to the caller what to do inside the shell. This is really a shell provided by nix. And basically, shell is usually used to run executables that are found in $PATH
, what nix shell
provides.
I'm more concerned about nix develop
as it is not a noun and it is harder to say "start a nix develop" which is a verb. Maybe, dev-shell
/devshell
alias should be revived.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nix-shell-with-shebang/17088/2
During a discussion with @garbas , I learned that there was some "focus-group" testing for nix develop
naming. As a result, it turned out that developers who are unfamiliar with Nix understand the name nix develop
a lot better than nix dev-shell
. Perhaps the same experiment should be conducted for nix shell
? I propose the following:
I actually use alias use=nix-shell -p
for maybe 2 years or so now, IMHO it is not too ambiguous, it is quite on point, but I like the idea of nix bonk
^^.
https://github.com/NixOS/nix/issues/4609#issuecomment-1038967118 and so 71016402 show a need for custom shell launchers, which are best implemented via nix run
.
Perhaps nix develop
, or an equivalent that fits the chosen naming scheme, should behave like nix run .#startDevShell
before falling back to loading the devShell
attr?
What I normally think about nix-shell is that it adds an ephemeral program to my PATH, that is then discarded on exit
So what about:
$ nix try firefox
$ nix with firefox
$ nix one-time firefox
$ nix once firefox
$ nix try nixpkgs#gnugrep
The following binaries are now available in this (and only this) shell: egrep fgrep grep
nix-shell $ grep --version
nix-shell $ exit
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/do-we-have-the-right-verbs/18237/1
As a recently converted Nix/NixOS user I too found it difficult to separate nix shell
material in searches. However, I also find shell
describes the behaviour of nix shell
quite well and that it would be unfortunate to rename for search engines.
If you do change the name, I wonder whether nix sh
is an acceptable middle-ground, assuming sh
is treated separate from shell
by search engines?
I had the idea of nix shell-with
and nix shell-for
replacing nix shell
and nix develop
(also a bad name imo)
Since the guideline suggests the word to be a noun, I think nix shell-with
is the most unambiguous one because it literally provides a shell with whatever follows. I also like how it sounds declarative and not imperative.
This might just be the bikeshedding thread of the year.
@Raikiri If you think this is good, then you should check this one out https://github.com/divnix/digga/issues/429
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/what-would-you-like-to-see-improved-in-nix-cli-experience/24012/8
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-01-06-nix-team-meeting-minutes-21/24573/1
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nix-shell-nix-shell-and-nix-develop/25964/2
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-03-27-nix-team-meeting-minutes-44/26759/1
A while ago I observed that nix develop
and nix build
are essentially the same thing run in interactive or batch mode. Similar reasoning applies to nix shell
and nix run
, so we can imagine
# Adds firefox to the current shell session
$ nix get nixpkgs#firefox
# Just run the FF immediately
$ nix get --run nixpkgs#firefox
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-04-14-nix-team-meeting-minutes-48/27358/1
is confusing since there are also development shells (created by nix develop)
Can somebody explain to me the differente between nix shell and nix develop or point me to documentation that does this (understandably)?
Either bonk or inate would cause the user to read the manpage. I like both.
Really really don't do stuff like this. It is at the same time user hostile and trivializes your work.
is confusing since there are also development shells (created by nix develop)
Can somebody explain to me the differente between nix shell and nix develop or point me to documentation that does this (understandably)?
nix shell nixpkgs#wget
gives you a shell with the wget
program available for you to use. nix develop nixpkgs#wget
gives you a shell with all the tools needed to do development work on the wget software.
nix shell --help
and nix develop --help
seem to do a fairly good job of describing that - I guess the develop
one could be put in simpler terms?
I guess the
develop
one could be put in simpler terms?
I doubt it. This command is still about emulating the build environment, despite the name.
It should be re-done in a more minimal, less prescriptive way that's actually all about development. We'd welcome contributions in this area.
I really wish nix develop
would actually put me in an environment where I can run the whole build process of a package. Currently I need to create a temporary directory myself, I have to know which phases I need to execute and in what order and upon any error the shell will exit, requiring me to do everything all over again. It is hard for me to use this for actual package development.
If nix develop
would put me in a sandbox/environment where i can actually debug/determine how the derivation should look like, it would fit the description.
nix shell does what I expect it to do. Though I would expect it to have an option to inherit the environment from a derivation as well. This would allow inheriting from a mkShell derivation. This is in addition to adding packages to the shell environment ad-hoc, like nix shell currently does.
$ nix shell --from-derivation .#devShell --package nixpkgs#git
Would give me the shell environment of devShell, but also prepends nixpkgs#git to PATH
. So that git is available in the shell as well.
I can also imagine that nix shell
would have the option to print the environment instead of running it. --print-environment
would do the same thing as nix print-dev-env
, but for any nix shell
command.
Then all shell functionality resides in nix shell
. nix develop
can be repurposed under another name to do actual package development.
Running genericBuild
in a development shell usually does the extra steps of running each phase in succession. It doesn’t create a temporary directory to perform the build in however. You get a subdirectory of your current working directory.
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
nix inject
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.
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.
If
nix develop
would put me in a sandbox/environment
nix shell does what I expect it to do
Agree. nix shell
has some issues though (e.g. #8177), but not the naming, IMHO.
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.
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...
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.
nix environment
maybe?
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
The
nix shell
command replacesnix-shell -p
to provide a shell in which the specified packages are available. However, the namenix shell
is confusing since there are also development shells (created bynix develop
), which this isn't; and the oldnix-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.