[Tracking] Add Bazel support

[fmorency]

We want to be able to build this project and run its tests using Bazel.

[fmorency]

I've made some PoC in https://github.com/fmorency/bazelpoc and https://github.com/fmorency/bazelpoc_workspace.

I can build a rust project, as well as run tests.

I started porting many-rs but encountered a 'duplicated alias' issue in cargo-raze. The problem comes from the fact that we're using two versions of rand, one aliased.

[dependencies]
rand = "0.8"
rand-07 = { package = "rand", version = "0.7" } # Version compatible with ed25519-dalek

cargo-raze doesn't like it. I wrote an MRE in https://github.com/fmorency/bazelalias and commented in google/cargo-raze#474.

As a last attempt, I tried the PR in google/cargo-raze#512, but it doesn't fix the issue.

[fmorency]

I could build many-rs using crate_universe instead of cargo-raze.

My current PoC parses the Cargo.toml file and creates the necessary boilerplate to build the project with Bazel.

The next step of this project is to get rid of the Cargo.toml files and make Bazel the truth source. Cargo.toml and Cargo.lock should be generated by Bazel and not the other way around.

Lastly, I need to add tests and code coverage support.

[fmorency]

Build, tests, code coverage, fmt, and clippy work on https://github.com/fmorency/many-rs/tree/fmorency/enh-143-bazel with rules_rust git commit e83d5f3c77d2b41a0ad2fb9c5a0fb1dfb5e912a7. See the documentation on Coda.

Doc tests are failing because of bazelbuild/rules_rust#1233

[fmorency]

• Doc tests are working again since the many-rs refactor.
• rules_rust updated to 0.8.1, and code coverage now works properly.
• Added support to generate the rust-project.json file required by rust-analyzer. I still need to test this in VSCode.
• Some folks are working on the Bazel+Rust IntelliJ integration, but it's not ready yet. What appears to be a developer @ JetBrains told me on Slack that "we should get around to it soon".
  • Feature Request: Rust Support bazelbuild/intellij#675
  • Rust Support bazelbuild/intellij#3222
  • Support for Rust projects built with Bazel intellij-rust/intellij-rust#8491

TODO:

• Investigate how to perform a cargo update equivalent.
• Investigate how to create new command shortcuts, i.e., transform
  bazel build --aspects=@rules_rust//rust:defs.bzl%rustfmt_aspect --output_groups=fmt_checks //...:all-targets
  to
  bazel fmt //...:all-targets/

[hansl]

PR almost ready to merge, will close this.

[fmorency]

About the ability to publish a crate on crates.io from Bazel: bazelbuild/rules_rust#458

@UebelAndre said on Slack

I'm not aware of one, unfortunately. I think this is a complicated problem to solve since the artifacts uploaded to crates.io are bundled source code that will later be built with Cargo.

[fmorency]

I am on the fence as to the approach we're taking here.

I don't believe dropping Cargo and using Bazel as the single source of truth is the right approach for an open-source Rust project. Crate publishing, top-tier IDE support, etc., rely on Cargo.

Generating the Cargo manifest from Bazel was worked on in

bazelbuild/rules_rust#71

but it was pointed out in that

I'm of the opinion that generating Cargo.tomls isn't possible in the general case, as Bazel's feature set is basically a superset of Cargo's feature set. That is to say that you don't have to look very far to find situations that can't be expressed via Cargo.tomls. Perhaps a means of siloing these parts of a source tree away (via hacky workarounds) could still prove useful...

We could instead use the Cargo manifest as the single source of truth and generate Bazel files from it. This use-case is supported by crate_universe. One drawback of supporting both Cargo and Bazel is

In cases where Rust targets have heavy interractions with other Bazel targests (Cc, Proto, etc.), maintaining Cargo.toml files may have deminishing returns as things like rust-analyzer begin to be confused about missing targets or environment variables defined only in Bazel. In workspaces like this, it may be desirable to have a “Cargo free” setup. 1

but I don't think it affects us at the moment.

I would be happy to discuss this with you @hansl.