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

Development Nix
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