"nix search" duplicate results in brand-new NixOS install. How to fix?

The nixpkgs -> . symlink? I have it too. I assume it’s there for a reason.

@layus @jonringer Do one of you know about that symlink? Is it supposed to be there? Seems like it causes the same channel to be treated like two channels, and shows the same results for “both channels”.

No, it’s so that it can resolve nixpkgs or the directory directly. Just a convenience to allow for some conventions to work

Oh ok. Is nixpkgs is the conventional one? Does that mean if I remove the symlink then things like let pkgs = import <nixpkgs> {}; won’t work?

this was discussed in detail at the office hours today, i would suggest taking a look:

Still trying to get to the bottom of this. Here is an excerpt of the git log for nixos/modules/services/misc/nix-daemon.nix. This show that nixos should not appear, at least when using the new nix xxx interface.

commit 9c53116d499f930f3b79a11ba1fa696623ebfcab
Author: Eelco Dolstra <edolstra@gmail.com>
Date:   Mon Sep 24 10:42:01 2018 +0200

    Revert "nixos: set nixos in nixPath"
    This reverts commit 67c8c4917799496dcf2ad6a500441fbbaeb918c9.
    'nix run nixos.firefox' is *not* supposed to work - the Nix 2.x
    interface attempts to standardize on nixpkgs.*, to get rid of the
    nixos/nixpkgs confusion that existed with the channels interface. So
    let's not bring that confusion back.

commit 67c8c4917799496dcf2ad6a500441fbbaeb918c9
Author: Matthew Bauer <mjbauer95@gmail.com>
Date:   Sun Sep 23 00:14:27 2018 -0500

    nixos: set nixos in nixPath
    This makes using the nixos channel work out of the box with the new
    Nix commands. For example:
    $ nix run nixos.firefox -c firefox
    Fixes #46536

I would bet that on your system the following command works ?

nix run nixos.firefox -c firefox

On mine it fails with

$ nix run nixos.firefox -c firefox
error: attribute 'nixos' in selection path 'nixos.firefox' not found

For you it should build firefox and run it. If it is indeed the case, I have a long and complex command that could get us a bit further :wink:

nix run nixos.firefox actually starts compiling something on my machine. I guess I have this problem too. Unfortunately nix search -u runs out of memory and crashes on my machine (it does this when I have 2 channels set up; I don’t remember what the output looked like when I only had 1 channel) so I can’t verify that it’s showing duplicate output.

Looking at that commit, I’m assuming this is the code that populates $NIX_PATH? My $NIX_PATH doesn’t contain a nixos=… entry, so this commit is working, and yet nixos.firefox still resolves.

This is what I got as root:

# nix run nixos.firefox -c firefox
[1 copied, 0.0 MiB DL]
Running Firefox as root in a regular user's session is not supported.  ($XAUTHORITY is /run/user/1000/gdm/Xauthority which is owned by trusktr.)

EDIT: works fine as normal user. But either way it resolve nixos.firefox.

firefox, as an application, will fail if it’s started by root

you probably want:

$ nix run nixpkgs.firefox -c firefox

however, this is starting to greatly diverge from the original thread topic

Well back to @layus’s thought, both

$ nix run nixpkgs.firefox -c firefox 


$ nix run nixos.firefox -c firefox 

work. @layus thought that, based on those commits, only one should work.

Even if they both should work, it’s redundant to see both, especially for a beginner who will wonder why.

My assumption is nixos.firefox exists (on my machine) because $NIX_PATH contains /nix/var/nix/profiles/per-user/root/channels, which is a directory that has a symlink nixos inside it. $NIX_PATH also contains nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos, which means that <nixpkgs> and <nixos> refer to the same path. So it’s not surprising that both attribute paths work.

I guess the real question is, should nix search be returning “duplicate” results or not? I hope it’s smart enough at least to only index the path once even though it’s reachable from two different attributes.

For extra confirmation, I see this in the nix repl:

$ nix repl
Welcome to Nix version 2.3.1. Type :? for help.

nix-repl> <nixpkgs>

nix-repl> <nixos>

I found the source of the discrepancy. I was using nixUnstable, in a version that did not yet receive a patch that has been cherry-picked to nix 2.3.

The behavior of supporting channels, and hence finding the nixos channel was introduced in 1d5cb6ad4839a50a96c27c94f19adcb97b6391af:

commit 1d5cb6ad4839a50a96c27c94f19adcb97b6391af
Author: Eelco Dolstra <edolstra@gmail.com>
Date:   Wed Oct 9 15:36:51 2019 +0200

    getSourceExpr(): Handle channels
    Fixes #1892.
    Fixes #1865.
    Fixes #3119.
    (cherry picked from commit e6e61f0a54dac0174df996e93fcfedcac7769ab4)

Mark the linked comment from Eelco:

No, it’s not a bug. Rather, the nix command does not have a replacement for channels yet, so it’s currently left undefined where it gets its inputs from. (This is one of the main reasons why the nix CLI is marked experimental.) So currently it only uses prefixed NIX_PATH elements like nixpkgs=... .

I guess at some point Eelco changed his mind due to the number of bugs filed, and added support for channels in there. Benefit is that nix now sees them, the downside is that some entries may appear twice.
You can try to report this bug, but where, and to whom I am not sure.
Not sure if there is a proper fix in the meantime either.

Basically, this falls in the “nix command is still experimental” kind of WONTFIX (yet) issues.

1 Like

When I install nix inside Ubuntu with curl, I get single results when I search for packages. After I install NixOS on a hard disk and boot into it, I get double results when I search for packages. There’s an inconsistency here, as both environments are behaving differently.

Another inconsistency is that nix-channel --list only shows nixos, which then causes search results not to match with expectations (because why we’re seeing search results for a channel that isn’t listed in the list of channels).

Seems like something needs TLC here, but I’m not experienced enough yet to be able to make that contribution.

Yeah, getting double results in nix search is not great UX, but it’s much much better than the situation before that commit where non-NixOS users were getting no results in nix search by default.

I didn’t know about that; it’s definitely bad to see no results.

As a beginner, the double results made me think I might’ve been doing something wrong.