Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed

Conversation

ElvishJerricco
Copy link
Contributor

Helps with #1930

@ElvishJerricco
Copy link
Contributor Author

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
Copy link
Contributor Author

Alright, fixed it by clearing stderr first.

@grahamc
Copy link
Member

grahamc commented Mar 10, 2019

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

@7c6f434c
Copy link
Member

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
Copy link
Contributor Author

@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
Copy link

xaverdh commented Oct 24, 2020

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
Copy link

xaverdh commented Oct 24, 2020

(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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants