Verbose option for nixpkgs_package #85
Comments
mboes
added a commit
that referenced
this issue
Apr 12, 2020
Historically, the user was able to see the output of `nix-build` in real-time. This was useful, because building derivations can take a long time. Even if the binary cache can be used for all derivations, downloading can take a long time. Then #77 came along, which made `nix-build` quiet as a side-effect. Later, #86 subsumed #77 with a simpler implementation. However, people argued in #82 that being quiet is the right thing to do, because otherwise workspace rule output can garble the output of `bazel query` and break scripts. So we stuck to quiet output and this was called out in the v0.6 changelog. It turns out that the problem affects other rule authors too (see bazel-contrib/rules_nodejs#583). This led to bazelbuild/bazel#10611, which fixes the problem for everyone, and shipped in Bazel 3.0. Now, all workspace rule output goes to `stderr`, so scripts calling `bazel query` shouldn't be affected. Given this upstream change, my position is that being verbose is now the right thing to do. If #85 is implemented, then being verbose should remain the default, at least for users of Bazel 3.0 onwards. Because even small packages may have a large set of dependencies that must be downloaded first. It's nigh impossible for the author of the workspace file to anticipate the state of the user's cache.
mboes
added a commit
that referenced
this issue
Apr 12, 2020
`nixpkgs_package` can now optionally be quiet, like it is in v0.6. This is useful for users of Bazel older than v3.0 who pipe the output of `bazel query` to scripts and don't want workspace rules to pollute the output of the query. Closes #85
mboes
added a commit
that referenced
this issue
Apr 15, 2020
Historically, the user was able to see the output of `nix-build` in real-time. This was useful, because building derivations can take a long time. Even if the binary cache can be used for all derivations, downloading can take a long time. Then #77 came along, which made `nix-build` quiet as a side-effect. Later, #86 subsumed #77 with a simpler implementation. However, people argued in #82 that being quiet is the right thing to do, because otherwise workspace rule output can garble the output of `bazel query` and break scripts. So we stuck to quiet output and this was called out in the v0.6 changelog. It turns out that the problem affects other rule authors too (see bazel-contrib/rules_nodejs#583). This led to bazelbuild/bazel#10611, which fixes the problem for everyone, and shipped in Bazel 3.0. Now, all workspace rule output goes to `stderr`, so scripts calling `bazel query` shouldn't be affected. Given this upstream change, my position is that being verbose is now the right thing to do. If #85 is implemented, then being verbose should remain the default, at least for users of Bazel 3.0 onwards. Because even small packages may have a large set of dependencies that must be downloaded first. It's nigh impossible for the author of the workspace file to anticipate the state of the user's cache.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
nixpkgs_packageis not verbose at all and sometimes users can observe a bazel process stuck onfetching @some_packagebecause the underlying nix process takes time. See #82 for a more detailled discussion.In #82 I proposed to introduce a new attribute to
nixpkgs_package,quiet. This attributes copies the behavior of the similarly named parameter of therepository_ctx.executefunction:Trueby default, meaning no output (the current behavior), but can be switchedFalseby the user, meaning that the output of the underlying subprocess is copied verbatim to bazel outputs.In this issue, I propose that we implement this attribute.
Note that we cannot just switch back to
quiet = Falseby default because it will leaksnixoutput to bazel output in all cases, which may break scripts using, for example,bazel query.This work is blocked by the resolution of #84 because for now
nix-buildis too verbose.The text was updated successfully, but these errors were encountered: