-
Notifications
You must be signed in to change notification settings - Fork 81
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
Bazel 027 #957
Conversation
See NixOS/nixpkgs#63532 for nixpkgs upstream work. |
da215a2
to
a6376a5
Compare
Ok, the only remaining task is to wait for the nixpkgs upstream PR to be merged. Once |
9540199
to
f4f4b13
Compare
Yeah, I found that: bazelbuild/bazel#8723 which was the reason why bindist was not green. Everything is green! Cleaning and converting to a real PR. |
- bazel 0.27 will default to python3 in this context - I removed the "hackish" print statement, it does not crash. I assume the issue is fixed. - list > int is not valid in python3 (it was always True in python 2)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thank you!
Thank you @aherrmann for the PR approval. I'll fix the space issue and the regression on windows (probably due to the latest rebase, I'll see) and I merge. |
8d34ad4
to
342be04
Compare
The amount of shell indirection seems to have changed in Bazel 0.27. Meaning that we would need twice as many `\` for the `sed` call on Windows. The `tr` command is insensitive to single backslashes, so it's an easier alternative.
See: bazelbuild/bazel#5825 Needs a protobuf update. Note: the new protobuf needs zlib dependencies which are provided by using protobuf_deps.
Executables must be passed as `tools` instead of `inputs`. See: bazelbuild/bazel#5826
See: bazelbuild/bazel#7793 buildifier needed an update of buildtools and rules_go, and starting from rules_go 0.17.0, it must be loaded using go:deps.bzl.
Summary of the tasks done for this PR.
ijar
ld loadercheckPhase
issuescpu
attribute--incompatible_disable_genrule_cc_toolchain_dependency
--incompatible_no_transitive_loads
--incompatible_disable_deprecated_attr_params=false
--incompatible_new_actions_api=false
--incompatible_no_support_tools_in_action_inputs=false
--incompatible_require_ctx_in_configure_features=false
--incompatible_depset_is_not_iterable=false
--incompatible_depset_union=false
--incompatible_use_python_toolchains=false
--build_tag_filters
are not taken into account, leading to the build of thenixpkgs_package
targets.Open issue
--incompatible_use_python_toolchains
is a pain to manage with the three platform we use. For now it was reactivated. The code for the python toolchain (working on linux / darwin nixpkgs) is still here, but the toolchain is not used and--incompatible_use_python_toolchains=false
is set in.bazelrc
.That's difficult to fix considering that the windows python autodetection bazel script is not functional (bazel issue reported in comments). I think it is a correct tradeoff for now, considering that it won't leak in user code. That's only used for our tests, so I prefer keeping it simple for now and wait for future bazel upgrade which may comes with a functional windows autodetection script.
This closes #956 and #948.