rules_rust@0.34.1 #1199

publish-to-bcr-bot · 2023-12-15T23:56:23Z

Release: https://github.com/bazelbuild/rules_rust/releases/tag/0.34.1

Author: @scentini

fyi: @UebelAndre, @illicitonion

Automated by Publish to BCR

fmeum

Placeholder for a review, please don't merge yet

fmeum · 2023-12-17T11:19:11Z

modules/rules_rust/0.34.1/MODULE.bazel

+ version = "0.34.1",
+)
+
+print("WARNING: The rules_rust Bazel module is still highly experimental and subject to change at any time. Only use it to try out bzlmod for now.") # buildifier: disable=print


prints in module files are displayed when the module file is evaluated, which happens during version resolution and thus even if this module doesn't end up being selected. For this reason, getting rid of this warning is extremely difficult as you need to make sure its never mentioned by any module file in the full transitive closure. The only way is usually to yank these versions and even that required changes to Bazel (bazelbuild/bazel@2a2a474). We tried this in rules_go and now consider it a mistake.

Instead, if you really want to show this warning (we learned that almost nobody cared), I would recommend doing so from a module extension. That way, the warning is only shown if that version of the module is selected and actually used.

I added this warning, but only did so because rules_go did so and so I thought it was best practice. Happy to remove it.

Fix is in bazelbuild/rules_rust#2345.

fmeum · 2023-12-17T11:21:52Z

modules/rules_rust/0.34.1/MODULE.bazel

+rust = use_extension("//rust:extensions.bzl", "rust")
+
+# Allow us to run, for example, "bazel build //tools/runfiles" with bzlmod.
+# Register it as a dev dependency so that we don't force this toolchain on
+# downstream users.
+rust.toolchain(edition = "2021")
+use_repo(rust, "rust_toolchains")
+
+register_toolchains(
+ "@rust_toolchains//:all",
+ dev_dependency = True,
+)
+
+use_repo(rust, "rust_host_tools")


Do you really want to declare the toolchain tag as a non-dev dependency, but then only register the toolchain as a dev dependency? Based on the comment, I would have expected the rust extension usage to also come with dev_dependency = True.

What is the story around default toolchain registrations for rules_rust? If a ruleset needs to compile a rust tool from source, can it rely on some "reasonable" Rust toolchain being registered even if the root module itself doesn't use rules_rust?

Ah yeah, it should probably either be use_extension as a dev dependency or register toolchains without a dev dependency. My intention was to ensure that it was explicit and that you didn't accidentally use the default toolchain when you'd intended to use a custom one, so I'd intended for use_extension to be a dev dependency.

However, I'd like to hear your opinion on best practices. Is one option preferred over the other?

As Xudong likes to put it, all of us are just "winging it" when it comes to Bzlmod - it's too early proven best practices. What I found to work well so far is to have rulesets with relatively canonical SDKs (mostly not C++) promise to always register some reasonably recent version of a hermetic SDK so that transitive deps of a project can use rust_binary without placing the toolchain resolution burden on the root module. That does seem to work for Go, but whether it makes sense for Rust depends a lot on the ecosystem.

I believe this is fixed by bazelbuild/rules_rust#2351.

Does this still allow the root module to override the toolchain used?

Yes. According to the bazel docs, the toolchain resolution is:

Toolchains registered using --extra_toolchains are added first. (Within these, the last toolchain has highest priority.)

Toolchains registered using register_toolchains in the transitive external dependency graph, in the following order: (Within these, the first mentioned toolchain has highest priority.)

Toolchains registered by the root module (as in, the MODULE.bazel at the workspace root);

Toolchains registered in the user's WORKSPACE file, including in any macros invoked from there;

Toolchains registered by non-root modules (as in, dependencies specified by the root module, and their dependencies, and so forth);

Toolchains registered in the "WORKSPACE suffix"; this is only used by certain native rules bundled with the Bazel installation.

All you need to do is to call register_toolchains from the root module, and you should be able to override the toolchains.

fmeum · 2023-12-17T11:23:43Z

modules/rules_rust/0.34.1/presubmit.yml

@@ -0,0 +1,647 @@
+---
+aspects_flags: &aspects_flags


This collection of checks looks very heavy. Most Bzlmod-related failures can already be verified by running just the analysis phase. Given the already heavy load on the bazelbuild CI, would it be possible to cut this down and/or sprinkle in uses of --nobuild?

CC @meteorcloudy who knows the state of the CI system better

Thanks! Yes, I totally agree with @fmeum. The presubmit.yml file in the BCR is not meant to run all the integration/unit tests in your normal CI pipeline. It should be a few integration tests that cover the most common usages of this module. Ideally, by including a test module

I will propose a simpler pre-submit check as the full set of checks will have already run for the PRs.

I put up a PR which introduces a rules_bazel_integration_test that builds and runs a hello world using rules_rust.

Fixed by bazelbuild/rules_rust#2347.

illicitonion · 2023-12-19T13:53:32Z

/cc @matts1 @cgrindel - as y'all have been driving most of the bzlmod pieces here, could y'all coordinate to address the above comments?

Related to bazelbuild/bazel-central-registry#1199 (comment).

See discussion in github.com/bazelbuild/bazel-central-registry/pull/1199

…2347) - Create `bzlmod/hello_world` package based upon `examples/bzlmod/hello_world`. - Add `rules_bazel_integration_test` so that `//bzlmod:hello_world_test` can be executed as a test from the parent workspace. - Add `filegroup` targets named `all_files` to collect files for all of the packages that are necessary to use `rules_rust`. These are an input to the `rules_bazel_integration_test` test. - Replace `.bcr/presubmit.yml` to test `//bzlmod:hello_world_test`. - Update CI to test `//bzlmod:hello_world_test`. Related to bazelbuild/bazel-central-registry#1199 (comment).

cgrindel · 2023-12-28T14:20:13Z

@fmeum @matts1 I think that we can close this PR. All of the issues have been fixed and a release has been merged to the BCR. Do you concur?

Publish bazelbuild/rules_rust@0.34.1

71d4d75

dtolnay mentioned this pull request Dec 16, 2023

Add configuration to mirror github releases to bazel central registry bazelbuild/rules_rust#2256

Merged

fmeum added the presubmit-auto-run Presubmit jobs will be triggered for new changes automatically without reviewer's approval label Dec 16, 2023

fmeum requested changes Dec 16, 2023

View reviewed changes

fmeum reviewed Dec 17, 2023

View reviewed changes

cgrindel mentioned this pull request Dec 20, 2023

chore: remove print from MODULE.bazel bazelbuild/rules_rust#2345

Merged

illicitonion pushed a commit to bazelbuild/rules_rust that referenced this pull request Dec 20, 2023

chore: remove print from MODULE.bazel (#2345)

486553f

Related to bazelbuild/bazel-central-registry#1199 (comment).

cgrindel mentioned this pull request Dec 20, 2023

chore: add //bzlmod:hello_world_test and use it as BCR presubmit bazelbuild/rules_rust#2347

Merged

matts1 added a commit to matts1/rules_rust that referenced this pull request Dec 22, 2023

Register a toolchain by default in MODULE.bazel

802fe9f

See discussion in github.com/bazelbuild/bazel-central-registry/pull/1199

matts1 mentioned this pull request Dec 22, 2023

Register a toolchain by default in MODULE.bazel bazelbuild/rules_rust#2351

Merged

illicitonion pushed a commit to bazelbuild/rules_rust that referenced this pull request Dec 22, 2023

Register a toolchain by default in MODULE.bazel (#2351)

443192a

See discussion in github.com/bazelbuild/bazel-central-registry/pull/1199

fmeum closed this Dec 28, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rules_rust@0.34.1 #1199

rules_rust@0.34.1 #1199

publish-to-bcr-bot bot commented Dec 15, 2023

fmeum left a comment

fmeum Dec 17, 2023

matts1 Dec 19, 2023

cgrindel Dec 20, 2023

fmeum Dec 17, 2023

matts1 Dec 20, 2023

fmeum Dec 20, 2023

cgrindel Dec 28, 2023

cameron-martin Jan 11, 2024

matts1 Jan 12, 2024

fmeum Dec 17, 2023

meteorcloudy Dec 19, 2023

cgrindel Dec 20, 2023

cgrindel Dec 20, 2023

cgrindel Dec 28, 2023

illicitonion commented Dec 19, 2023

cgrindel commented Dec 28, 2023

rules_rust@0.34.1 #1199

rules_rust@0.34.1 #1199

Conversation

publish-to-bcr-bot bot commented Dec 15, 2023

fmeum left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

illicitonion commented Dec 19, 2023

cgrindel commented Dec 28, 2023