nix build: Print result paths to stdout with --no-link

[ElvishJerricco]

Helps with #1930

[ElvishJerricco]

I've been using this PR on my machine for a while now by applying the patch on the system's Nix package. It's been really useful so far, so I'd love to see this merged.

But I've had one problem with it, at least with Nix 2.1.1. When Nix outputs querying info about missing paths, it ends up looking like:

$ nix build --no-link nixpkgs.ghc
querying info about missing paths/nix/store/n5i1zdpmk2b1s3z96649xh8f9kr3g96s-ghc-8.4.3

Now, that's not on stdout, so it has no functional issue.

$ nix build --no-link nixpkgs.ghc | cat
/nix/store/n5i1zdpmk2b1s3z96649xh8f9kr3g96s-ghc-8.4.3

But it is rather annoying. Anyone know what I should do about this?

[ElvishJerricco]

Alright, fixed it by clearing stderr first.

[grahamc]

This is unsafe, as it leaves a race condition of the build finishing, GC, and the path being used.

[7c6f434c]

I do think this race condition is manageable in most cases, as auto-GC is probably used only on a minority of deployments, but of course it would be even nicer to have some orthogonality, and maybe just the approach of always printing as in #2622 is the best.

[ElvishJerricco]

@grahamc I don't think that's solvable. Once our process exits, we have no way to guarantee to the user that the paths will remain in the store without a link. Personally I consider this an edge case. Since I find this feature to be mostly a convenience for when I'm messing around interactively, I'd much rather see that listed as a warning in the --help text than used as a reason not to merge something like this.

[xaverdh]

This is unsafe, as it leaves a race condition of the build finishing, GC, and the path being used.

Using symlinks in the current directory (the default behaviour) is also racy. If two builds are running with the same cwd, one might overwrite the symlink from the other, before the caller reads it. Using temporary directories slightly improves the situation, assuming these are sufficiently "protected" (e.g. by a private mount namespace or such).

[xaverdh]

(e.g. by a private mount namespace or such)

which will not work actually, now that I think of it.. the daemon needs to be able to see the symlink