nix build -f appears not to work when invoked with an expression

[bgamari]

The following fails

$ nix build -f '<nixpkgs>' '(haskellPackages.callCabal2nix "html-parse" ./. {})'
error: undefined variable 'haskellPackages' at (string):1:2

Despite the fact that haskellPackages is an attribute of <nixpkgs> evidenced by,

$ nix build -f '<nixpkgs>' haskellPackages
error: Package ‘Elm-0.13’ in /nix/store/ycfbpfpgbj5pwlsasxbxddpfdynndnyg-nixos/nixos/pkgs/development/haskell-modules/hackage-packages.nix:4834 is marked as broken, refusing to evaluate.

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

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

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

[edolstra]

-f has no effect on expression installables. Try nix build '((import <nixpkgs> {}).haskellPackages...)'.

[bgamari]

Hmm, that is rather surprising; shouldn't a warning be thrown in this case?

Regardless, it seems like a preferable semantics would be for -f to determine the context in which the expression is evaluated. Am I missing a reason why this isn't feasible?

[bgamari]

To express the inconsistency a bit more clearly: it's quite surprising to me that I can write nix build -f '<nixpkgs>' hello but not nix build -f '<nixpkgs>' '(hello)'. As far as I can tell there is no good reason for this; it's entirely possible for expressions and -f to interact.

I think that changing the command-line semantics of nix build to the following would resolve this inconsistency in an intuitive and backwards compatible manner:

1. If only an expression is given (e.g. nix build '(hello)'): evaluate the expression in the default environment (i.e. populated with the usual bindings from NIX_PATH)
2. If only -f $FILE is given: evaluate import $FILE (adding arguments as necessary)
3. If both -f $FILE and an expression are given: evaluate with (import $FILE $args1); $EXPR $args2, where $args1 and $args2 are the arguments specified by --arg accepted by (import $FILE) and $EXPR, respectively.
4. if -f $FILE is given without an expression: evaluate import $FILE $args
5. if -f $FILE is given with an attribute: do the current recursive application behavior inside a with (import $FILE $args) block.
6. if only an attribute is given: same as (5), but evaluated in the default environment.

As far as I know of these only (3) and (5) differ from the status quo; moreover, these only change the behavior of cases which are currently handled in a surprising manner (namely by ignoring the user's -f argument).

[stale]

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

[stale]

I closed this issue due to inactivity. → More info