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

Print built derivations as json for build #4182

Merged
merged 2 commits into from Nov 17, 2020
Merged

Conversation

@mkenigs
Copy link
Contributor

@mkenigs mkenigs commented Oct 23, 2020

Add --json option to nix build to allow machine readable output on
stdout with all built derivations

Fixes #1930

I think closes #2423 and #1647

Wasn't quite sure is there a better place to put a test?

Copy link
Contributor

@regnat regnat left a comment

That looks good overall, except that it brings back the intentionally removed behavior of printing the built store paths 🤔

(Ftr, and unless I misunderstood the matter, the issue with printing these paths is that they don't come with any guaranty of not being gc-ed if --no-link is passed or the symlinks are removed, bringing back some scary memories of use-after-free)

src/nix/installables.hh Outdated Show resolved Hide resolved
tests/build.sh Outdated Show resolved Hide resolved
@dasJ
Copy link
Member

@dasJ dasJ commented Nov 6, 2020

That looks good overall, except that it brings back the intentionally removed behavior of printing the built store paths thinking

@regnat There was still nobody whould could explain to me why $(nix build)/bin/whatever is an antipattern. The only "explanation" is the gc which is completely irrelevant in cases where I just want to execute a tool and I can just retry when it fails.
There is no alternative to this workflow (except this PR which requires me to ADDITIONALLY use jq (with its annoying syntax) instead of just $()

@regnat
Copy link
Contributor

@regnat regnat commented Nov 6, 2020

@regnat There was still nobody whould could explain to me why $(nix build)/bin/whatever is an antipattern. The only "explanation" is the gc which is completely irrelevant in cases where I just want to execute a tool and I can just retry when it fails.

I don't want to enter this debate. I didn't state any position, just noted that it might be controversial. But fwiw:

There is no alternative to this workflow (except this PR which requires me to ADDITIONALLY use jq (with its annoying syntax) instead of just $()

There are cases where it wouldn't work, but nix shell --run whatever actually does what you want (and is arguably nicer).

@mkenigs
Copy link
Contributor Author

@mkenigs mkenigs commented Nov 10, 2020

Thanks @regnat , applied those changes

@mkenigs
Copy link
Contributor Author

@mkenigs mkenigs commented Nov 11, 2020

@regnat I think including json_fwd requires passing PRECOMPILE_HEADERS=1 to make. Is that okay? And would that need to be added to the nix-shell instructions for make at https://nixos.org/manual/nix/unstable/hacking.html?

@regnat
Copy link
Contributor

@regnat regnat commented Nov 11, 2020

@regnat I think including json_fwd requires passing PRECOMPILE_HEADERS=1 to make. Is that okay? And would that need to be added to the nix-shell instructions for make at https://nixos.org/manual/nix/unstable/hacking.html?

No that shouldn't. I guess what's happening is that installables.cc was transitively including json.hpp via installables.hh.
So you need to explicitely include json.hpp in installables.cc.

The reason why it works with PRECOMPILE_HEADERS=1 is that this flag cause the compiler to first bundle all the external headers (including json and json_fwd) into one big precompiled thing precompiled-headers.h.gch which is systematically included. This is faster than all the individual includes because of the precompilation step, but the consequence is that when that flag is set all the external includes are redundant.

@mkenigs
Copy link
Contributor Author

@mkenigs mkenigs commented Nov 11, 2020

There are cases where it wouldn't work, but nix shell --run whatever actually does what you want (and is arguably nicer).

What are cases where you really do need nix build? To me it seems like even out links are pretty inconsistent with nix philosophy, since they can be left anywhere, rather than managed declaratively. nix shell --run whatever seems a lot nicer to me.

@dasJ
Copy link
Member

@dasJ dasJ commented Nov 11, 2020

@mkenix Mainly for projects which are independent from nixpkgs. Not everything is fitted for nixpkgs, for example NixDroid.

mkenigs added 2 commits Nov 11, 2020
Add --json option to nix build to allow machine readable output on
stdout with all built derivations

Fixes NixOS#1930
@edolstra edolstra merged commit f4e790c into NixOS:master Nov 17, 2020
2 checks passed
2 checks passed
@github-actions[bot]
tests (ubuntu-latest)
Details
@github-actions[bot]
tests (macos-latest)
Details
@edolstra
Copy link
Member

@edolstra edolstra commented Nov 17, 2020

Thanks!

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

Successfully merging this pull request may close these issues.

4 participants