nix-env silently fails to install unfree packages

[obadz]

nix-env silently fails to install unfree packages when allowUnfree = false; and returns success:

$ nix-env -iA nixpkgs.unrar
$ echo $?
0
$ nix build nixpkgs.unrar
error: Package ‘unrar-5.5.8’ in <nixpkgs>/pkgs/tools/archivers/unrar/default.nix:39 has an unfree license (‘unfreeRedistributable’), refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

(use '--show-trace' to show detailed location information)

Feels like it should display the same error that nix build does.

[obadz]

Both with nix-1.11 and nix-2

[dtzWill]

Thanks for reporting, this is no good!

I can reproduce, but after some investigation it seems this only happens with recent nixpkgs:

$ nix-env -f channel:nixos-17.09 -iA unrar
error: while evaluating 'callPackageWith' at /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/lib/customisation.nix:113:35, called from /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/pkgs/top-level/all-packages.nix:4957:11:
while evaluating 'makeOverridable' at /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/lib/customisation.nix:72:24, called from /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/lib/customisation.nix:117:8:
while evaluating anonymous function at /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/pkgs/tools/archivers/unrar/default.nix:1:1, called from /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/lib/customisation.nix:74:12:
while evaluating 'mkDerivation' at /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/pkgs/stdenv/generic/make-derivation.nix:15:5, called from /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/pkgs/tools/archivers/unrar/default.nix:3:1:
while evaluating 'addPassthru' at /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/lib/customisation.nix:135:22, called from /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/pkgs/stdenv/generic/make-derivation.nix:166:7:
while evaluating anonymous function at /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/pkgs/stdenv/generic/check-meta.nix:5:1, called from /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/pkgs/stdenv/generic/make-derivation.nix:167:22:
while evaluating 'handleEvalIssue' at /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/pkgs/stdenv/generic/check-meta.nix:128:21, called from /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/pkgs/stdenv/generic/check-meta.nix:203:17:
Package ‘unrar-5.5.8’ in /nix/store/kzrzq8fca5grj82rrq9xmz3yz1vr5gpl-nixexprs.tar.xz/pkgs/tools/archivers/unrar/default.nix:36 has an unfree license (‘unfreeRedistributable’), refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

Pointing at unstable:

$ nix-env -f channel:nixos-unstable -iA unrar

So perhaps the problem is with nixpkgs?

[dtzWill]

Okay bisected the change to this commit:

NixOS/nixpkgs@50148f0

Which links to #1771, although from a quick read I'm not sure this is known/"expected"?

Hopefully folks from that issue have some insights and suggestions :).

[obadz]

Thanks @dtzWill !

[oxij]

Yeah, see NixOS/nixpkgs#33057 (comment). As I said in that issue and in #1771 nix-env filtering behavior is fundamentally broken. So I'm not surprised something else that uses this "feature" broke after #33057. The fact it worked before was a historical accident that required derivations to be strict. #33057 made derivations lazy with many benefits nixpkgs already uses extensively. I find it unlikely that anyone now wants to revert #33057 and get slower evaluation with no free universal `.meta` access (a whole bunch of derivations now use it). Hence, I see two options: * Add more workarounds to nixpkgs like #33057 had to do for "normal nix package filtering". I'm not sure how to work around this particular issue, though, as `nix-env` seems to be very idiosyncratic on what it considers an evaluation failure. * Fix nix itself. SLNOS patches nix with an updated version #1771 (that looks at `.meta.available` instead of `.meta.evaluates`). I can update #1771 to reflect that, but since it got some pushback from @edolstra I find it unlikely that the exact change would get merged unless @edolstra changes his mind. So, feel free to do whatever. Also feel free to use the code from #1771 in any way you want.

[oxij]

Btw, I just checked and #1771 indeed fixes this.

[akavel]

Just stumbled upon this when trying to install VSCode. Had no idea what to do. Only after running nix-env with -v flag, seeing "license.nix" as one of listed files, and being lucky enough to recall that an "allowUnfree" flag is a thing, I was able to resolve this for myself. If I was just a tad bit more newbie, with the empty output I'd stand no chance to resolve this, other than asking on Nix Discourse (having first to register on the forum).

[matthewbauer]

This is not actually a Nix bug - but a Nixpkgs one.

Fixed in NixOS/nixpkgs@ae16dd1

[oxij]

Won't that change other side effects like allowing to unconditionally install unfree packages with nix-env (with nix without a7e2049 of #1771 applied)?

[matthewbauer]

It still uses validity.handled, just not for the name attr: https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/make-derivation.nix#L307

[oxij]

IIRC from my testing in #1771, without that assert if you ask nix-env to install those derivations it will "install" them producing all the expected installation output, but then it will fail to generate the resulting profile spewing some incomprehensible error messages. See `installDerivations` function in `nix-env.cc` for details. Which is why one-line fix a7e2049 for that issue exists. Another side effect of removing that assert is that without #1771 `nix-env -qa` stops filtering its output (which might be okay, to be perfectly honest; personally, I think listing everything unless you specify `--out-path` or something should be fine, though that changes current expected behavior), which, for instance, breaks platform-dependence of `qaCount` nixpkgs metric (which, IMHO, is unfortunate and needs separate fixing if that change is not to be reverted for other reasons).

[matthewbauer]

Yes- I think we can fix the nix-env -qa count with an added --out-path arg. That gets me 19260 which I think is correct.

I'd much rather have those numbers be wrong though than get the really bad user experience of trying to install something and getting no output from Nix.

Before:

nixpkgs $ nix-env -f. -iA zoom-us

After:

nixpkgs $ nix-env -f. -iA zoom-us
installing 'zoom-us-2.6.149990.1216'
error: Package ‘zoom-us-2.6.149990.1216’ in /home/mbauer/nixpkgs/pkgs/applications/networking/instant-messengers/zoom-us/default.nix:98 has an unfree license (‘unfree’), refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

(use '--show-trace' to show detailed location information)

[stale]

I marked this as stale due to inactivity. → More info