`shell.nix` started printing an error (seems to still work though)

I have a simple setup for getting a shell to solve exercism exercises in that looks like this:

{pkgs ? (import (import ./nix/sources.nix).nixpkgs {})

with pkgs;

  shell-pkgs = with haskellPackages;

  mkShell {
    buildInputs = shell-pkgs;

With it I also have a .envrc:

use nix

The nix/sources.json contains

    "nixpkgs": {
        "branch": "nixpkgs-unstable",
        "description": "Nix Packages collection",
        "homepage": "",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "ab5b6828af26215bf2646c31961da5d3749591ef",
        "sha256": "13mcwbjh8j3mvmgv2z2kdbgpw0qy42jnanbxymj21n3hss0h7qrz",
        "type": "tarball",
        "url": "https://github.com/NixOS/nixpkgs/archive/ab5b6828af26215bf2646c31961da5d3749591ef.tar.gz",
        "url_template": "https://github.com/<owner>/<repo>/archive/<rev>.tar.gz"

This has worked fine in the past, but today, when I return to do some exercises after a fairly long pause, I’m greeted with the following on entering the folder:

❯ direnv reload
direnv: loading ~/Private/exercism/.envrc
direnv: using nix
error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)
warning: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I), at (string):1:9; will use bash from your environment
direnv: eval /home/magnus/Private/exercism/.direnv/cache-unknown
direnv: renewed cache and derivation link
direnv: export +AR +AR_FOR_TARGET +AS +AS_FOR_TARGET +CC +CC_FOR_TARGET +CONFIG_SHELL +CXX +CXX_FOR_TARGET +HOST_PATH +IN_NIX_SHELL +LD +LD_FOR_TARGET +NIX_BINTOOLS +NIX_BINTOOLS_FOR_TARGET +NIX_BINTOOLS_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_BINTOOLS_WRAPPER_TARGET_TARGET_x86_64_unknown_linux_gnu +NIX_BUILD_CORES +NIX_BUILD_TOP +NIX_CC +NIX_CC_FOR_TARGET +NIX_CC_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_CC_WRAPPER_TARGET_TARGET_x86_64_unknown_linux_gnu +NIX_CFLAGS_COMPILE +NIX_ENFORCE_NO_NATIVE +NIX_HARDENING_ENABLE +NIX_INDENT_MAKE +NIX_LDFLAGS +NIX_LDFLAGS_FOR_TARGET +NIX_STORE +NM +NM_FOR_TARGET +OBJCOPY +OBJCOPY_FOR_TARGET +OBJDUMP +OBJDUMP_FOR_TARGET +RANLIB +RANLIB_FOR_TARGET +READELF +READELF_FOR_TARGET +SIZE +SIZE_FOR_TARGET +SOURCE_DATE_EPOCH +STRINGS +STRINGS_FOR_TARGET +STRIP +STRIP_FOR_TARGET +TEMP +TMP +TMPDIR +__ETC_PROFILE_SOURCED +buildInputs +builder +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +name +nativeBuildInputs +nobuildPhase +out +outputs +patches +phases +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~PATH ~XDG_DATA_DIRS

What has changed and what do I need to adjust in order to not get an error each time I enter the folder?

Is the file nix/sources.nix present?

Yes, it’s present. Untouched since created by niv.

I was wondering if it might be something related to me effectively using nixpkgs unstable:

❯ nix-channel --list | grep nix
nixos-stable https://channels.nixos.org/nixos-20.09
nixpkgs https://nixos.org/channels/nixpkgs-unstable


❯ nix-env --version
nix-env (Nix) 2.4pre20210503_6d2553a

I’m not sure how to “downgrade” to latest stable release though :thinking:

The error suggests that there is somewhere a <nixpkgs> somewhere in the evaluated code.

Depending on your direnv version, this might actually be direnv that tries to run a shell for you, but then falls back to your environments shell.

Does the same error happen if you do not use direnv but run nix-shell instead?

Also please show your printenv NIX_PATH

Yes, the same thing, well almost, happens when using nix-shell:

❯ nix-shell
warning: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I), at (string):1:9; will use bash from your environment

There’s a <nixpkgs> in the code generated by niv (i.e. in ./nix/sources.nix).

❯ direnv --version

with nix-direnv-1.2.6. Not sure when either were last upgraded though.

As bare nix-shell gives the same error, it has to be related to niv then, unless of course you also have a project without niv that causes the same bessage beeing printed…

And you haven’t answered my question about the NIX_PATH.

I cleared out my user’s setup, and removed /nix and about to re-install to see if that sorts things out.

I don’t do anything with NIX_PATH myself, so I’m not sure what it was before re-installing.

After re-installing it’s /home/magnus/.nix-defexpr/channels:/home/magnus/.nix-defexpr/channels.

Oh, and the issue remains after the re-install :disappointed:

What is in ~/.nix-defexpr/channels?

❯ ls -l .nix-defexpr/channels/
total 20
lrwxrwxrwx 1 magnus magnus 67 Jan  1  1970 aws-helpers -> /nix/store/07w9c9pfwysh4jfazw72257vln91wc6m-aws-helpers/aws-helpers
lrwxrwxrwx 1 magnus magnus 71 Jan  1  1970 dhall-compose -> /nix/store/p7i57bmd3jyw9wp09rmbbzxcddqmm6bv-dhall-compose/dhall-compose
lrwxrwxrwx 1 magnus magnus 60 Jan  1  1970 manifest.nix -> /nix/store/plpn8p4fgcq9x59spwjk86mwsjzv53rh-env-manifest.nix
lrwxrwxrwx 1 magnus magnus 90 Jan  1  1970 nixos-21.05 -> /nix/store/804psk7z60y9h99h7s7pw74lqkj4ws55-nixos-21.05-21.05.2001.d4590d21006/nixos-21.05
lrwxrwxrwx 1 magnus magnus 61 Jan  1  1970 z-arthur -> /nix/store/lwbj69g3vvb8ssiwf9fq6pln5xvq3av4-z-arthur/z-arthur

There is no nixpkgs, and there is also nothing else that <nixpkgs> could resolve to.

The message will ge away once you nix-channel --add something named nixpkgs and nix-channel --update after adding

Oh, yes, that fixed it indeed. I wasn’t aware that <nixpkgs> resolved to a channel, I always thought that was the subfolder nixpkgs inside nixos-21.05. I guess it makes sense when it’s pointed out. Doesn’t seem to be info that’s easy to come by though, so thanks for your help @NobbZ .

<> are special pathes. They are resolved by looking them up in the NIX_PATH.

The nix path is a colon separated list, that can have “named” and “unnamed” entries.

First <> pathes are tried to get resolved via named entries, if the name isn’t found, then it looks in the subfolders in the unnamed entries, but only ever to the first default.nix IIRC.

(Simplified mechanism! Actual resolving is a bit more involved as also the manifest.nix is considered)

1 Like