What would you like to see improved in Nix cli experience?

Development Nix
44

A simple way to pipe nix repl output to a file.

Reason

I tried to achieve that or an nixosConfiguration earlier with builtins and lib functions, but failed. Since toJSON cannot handle functions inside a Set. Replacing them with dummy strings did not work either, since mapAttrsRecursive seemingly does not recurse deep enough to catch all.

45

Was writing from the top of my mind:

sudo nix-env --profile /nix/var/nix/profiles/system --delete-generations +3
46

That was not my complaint. The nix command implements new CLIs for both flakes and non-flakes, but they’re unified in a problematic way IMO. As I said, nix build .#foo and nix build -f . foo is an example where the CLI is unified but the behavior is significantly different.

47

but for nixpkgs the result is the same effectively.

48

Fo we have issues for this?

49

Probably not, it will happen eventually if someone has the courage to do it.

50

There’s no date in the actual store object, of course, but the system profile symlinks have a timestamp. nix-collect-garbage already implements --delete-older-than using these timestamps. I just want to be able to combine the already available criteria in a more useful way. There’s nothing wrong with that from a reproducibility perspective in my view. Are you saying that’s a reproducibility problem?

2 Likes
51

That makes sense. :+1:

52

Did someone mention this one yet:

$ nix-env --switch-profile PATH;
# TODO:
$ nix profile switch PATH;

AFAIK this is the last remaining nix profile CMD required to advise people “never use nix-env if you have migrated to flakes”. Having to tell coworkers “never use nix-env except to switch profiles” always feels icky and inevitably leads to a history lesson.

4 Likes
53

One annoyance is that nix run and nix bundle have no way of specifying an alternate binary when using a derivation, and it’s not clear how to from their manual pages. For example, if you want to run qalc from nixpkgs#qalculate, then I don’t think there’s a way using nix run (since nix run nixpkgs#qlalculate qalc tries to run /bin/qalculate with the argument qalc), and instead you need nix shell nixpkgs#qalculate -c qalc. Similarly, with nix bundle, if you only have a derivation and not an app, there’s no way to specify an alternate binary to use as the one that gets run when the bundle gets run. As far as I can tell, there’s not really a workaround for this.

4 Likes
54

Actually this is in the nix3-run man page explaining the sequence of how it determines what to run if the target is not an app:

         • The meta.mainProgram attribute of the derivation.
         • The pname attribute of the derivation.
         • The name part of the value of the name attribute of the derivation.

So you can add a meta.mainProgram = "qalc" for you example.

1 Like
55

None of that helps when a package exposes multiple binaries and you want a different one than is listed.

5 Likes
56

That’s great and all but A. that hasn’t happened for every package yet and B. there are packages with multiple executables in them you might want to use. I.e. ffmpeg and ffprobe are both in ffmpeg. Obviously you’d expect it to run ffmpeg by default and that makes sense but what if you wanted to run ffprobe instead?

I see no reason not to offer the user a choice which binary they wish to run. I’d see that as an integral part of the run subcommand. Something like nix run nixpkgs#ffmpeg ffprobe -i /path/to/file.mp4 should just work.

3 Likes
57

You can currently type the following, but I don’t endorse that it’s a good UX.

nix shell nixpkgs#ffmpeg -c /bin/sh -c "ffprobe -i /path/to/file.mp4"
1 Like
58

Yeah makes sense, the workaround given is pretty ugly too. It does seem a little weird that nix run and nix shell -c do almost the same thing, where the latter is just more explicit.

I left a comment on a recent PR of my mine and I’d like to drop a quote from it since it seems relavent to the overall point of this thread:

we may want to consider a more “plumbing” and “porceline” approach for flakes 2.0, to keep drift between the old and new commands from becoming a big issue.

I like the low-level control the legacy commands give me when I need that. Say in a complex CI system that focuses on doing as little work as possible, but I like the higher level commands for ease of use when working on my own system. I think there is an argument to be made for keeping both around and taking implementations from the lower-level commands and reusing them for their flake counterparts.

Perhaps I am missing something, but a more “git-like” approach may be the key to refining the UX in the future without sacrificing power where required.

6 Likes
59

Why not simply nix shell nixpkgs#ffmpeg -c ffprobe -i /path/to/file.mp4?

60

oh yeah, you’re right, this is working,

the /bin/sh -c wrapping should be used if you need to run a real shell command like ffprobe -i something && ffmpeg something else && whatever, which used to work with nix-shell but not with nix shell

61

I see. So lets fix -f there.

I spent several hours looking into this and here’s what I figured (not much):

  1. In nix search -f expr arg1 arg2 arg1 is always interpreted as an “installable”, which with -f means an attribute path of expr. So, in nix search -f expr arg1, arg1 is not the search string but an attribute path, hence the error.

  2. In nix search -f'<nixpkgs>' the “installable” defaults to "." but it’s parsed incorrectly: installable->getCursors(*state), which I suspect should return a pointer to some kind of tree (there’s hardly any comment in the nix codebase), produces the

    error: '' is not an attribute set

    This happens before any of the search/traversal logic of nix search, but that’s as far as I can get.

  3. There’s no syntax to refer to the top-level that nix seems to understand, but subsets work (somewhat, see the error at the end):

    $ nix search -f '<nixpkgs>' xorg bit
* bitmap (1.0.9)

* fontbitstream100dpi (100dpi-1.0.3)

* fontbitstream75dpi (75dpi-1.0.3)

* fontbitstreamtype1 (1.0.3)
error: 'packages' is not an attribute set

I guess this explain why the UI is so poor: unlike for Nixpkgs there’s only a dozen people that understand Nix and can fix it.

3 Likes
62

Regarding nix search behavior with nonflakes: Nix search: broken? - #7 by tejing

Short version, it’s searching the specified installable for legacyPackages.${system}.* like it was a flake…

63

One thing that has always bothered my colleagues, is that when using a flake input that asks for a password, the password request is hidden by Nix’s messages.

For example, doing nix build 'git+https://github.com/a/b' gives the impression that Nix is stuck at:

evaluating derivation 'git+https://github.com/a/b#packages.x86_64-linux.default'

But really, git is asking for an HTTP username and password.

I think the behavior is the same when using a password-protected SSH key (if that password is asked on the command-line of course).

5 Likes