I'm not sure why this PR was never merged. Just forgotten maybe? Or is there any objection?

In the meantime, for users who would like to continue using the otherwise nicer nix 2.0 commands, it's possible to get the best of both worlds by forking nix with an overlay:

$ cat ~/.config/nixpkgs/overlays/01-patches.nix
self: super: {
  nix = super.nix.overrideAttrs(_: {
    patches = [
      (super.fetchpatch {
        # Show build output with `nix build`. https://github.com/NixOS/nix/pull/1647
        url = "https://github.com/NixOS/nix/commit/d02e12f366a02acf34b458eb7530baf2bdc2d251.patch";
        sha256 = "1vbpnnb8mmrkqpmhb92cm9v44y711cqbyfhrbfdhxf643ayz1ngl";
      })
    ];
  });
}

Then nix build shows the built output!

$ nix-build '<nixpkgs>' -A nix                                                                
/nix/store/p2c6a8v6ww80h57gvclsdq4f1hzywmsi-nix-2.0.4

$(/nix/store/p2c6a8v6ww80h57gvclsdq4f1hzywmsi-nix-2.0.4/bin/nix build src.vim)/bin/vim --help | head -1
VIM - Vi IMproved 8.1 (2018 May 17, compiled Jan  1 1970 00:00:01)

Any updates on this patch?

I need this :( I don't like spraying result links everywhere for temporary builds.

@shlevy @copumpkin Could you have a look?

I feel that the nix command should not print things on stdout unless explicitly asked for. We should add a nix build --json flag for machine-readable output.

--json would be really nice to have, but I think most people want to use nix build in combination with bash for temporary builds. With only --json, jq would be required to use nix build ad-hoc in bash. Though I get that it probably shouldn't output anything by default.

What about --output-path?

Should we setup a poll for the community ?

1. Should nix build print the path by default ?
2. Should nix build create ./result by default ?

or do we have to discuss further options ?
This may be a good question for @NixOS/nix-core :-)

2. is a good question, since polluting the current directory is even worse than polluting stdout :-) So maybe --out-link should be required to create a result symlink.

Removing the directory pollution would be nice -- particularly when you run a bunch of builds and get result, result-1, result-2, ..., result-n in your dir.

Regarding the stdout, I'd say it's generally in line with most unix tools that they produce stdout, which makes it easy and convenient to pipe them to other commands in the shell. <cmd> | grep is a lot easier and more familiar than <cmd --json> | jq 'query' | grep. Usually if tools want to avoid spending stuff to stdout they have a --quiet or a --silent option.

Just to note I still find it interesting that the stdout solution is essentially a less reliable one (due to the GC). However, it is oh-so-convenient I must say. nix-shell and nix run have the right approach in the sense that while the shell/command is running, the GC cannot destroy the built paths.

For development I often do things like:

find $(nix build my-package-under-development --no-link)

or:

find $(nix-build crossPkgs.aarch64-generic.my-package-under-development --no-link)/bin | while read file; do file $file; done

I think it's fine there is a (almost non-existent) possibility that these commands fails due to the GC interferring. If there is a good 'best of both worlds' solution, I'm all ears :D

@edolstra There was pretty good suggestion from @ElvishJerricco to use something -o - which is explicit.

I consider that suggestion a compromise :P I'd much rather have output on stdout by default. I don't consider it pollution since it's just providing the result in a unix-y way

I don't think changing defaults is a viable way to go. There will be resistance to merge, because existing scripts will break. Maybe this is OK for Nix 2.0?

@bobvanderlinden The surface area for breakage caused by going from no output to some output seems small to me. Considering the Nix 2.0 commands are pretty explicitly marked experimental, I think this is ok.

Ah, yes, that seems fine. I thought removing the result symlink as well.

Think this should be closed by #4182?