bzlmod support

[keith]

It would be great if you could pull this repo in with bzlmod!

[siggisim]

Agreed - cc @sluongng

[siggisim]

cc @fmeum too in case you're looking for something lightweight to get started with

[marvin-hansen]

Much needed. I am converting a Bazel project and this is the only rule left.

[marvin-hansen]

There is a PR already in the making, so please upvote. Would be great to see this happening.

#27

[marvin-hansen]

Ok, you can actually keep using the existing rules in a Bazelmod configuration using the hybrid mode, as documented on the Bazel website.

You just crate a WORKSPACE.bzlmod file and add the rules from your previous WORKSPACE file.
I've added an example file here: https://gist.github.com/marvin-hansen/1441191edb8c5385d93f50c2624d9998

For any Bazel version before Bazel 7, you have to enable Bazelmod in the .bazelrc with

common --enable_bzlmod

However, upon the first run on BuildBuddy, you may encounter an error stating that rules_python must run in a non-root environment. I had this and the solution is relatively easy, you just override the error reporting. To do so, you add rules-python to your MODULE.bazel

# https://github.com/bazelbuild/rules_python/releases
bazel_dep(name = "rules_python", version = "0.33.1")

And the configure the python toolchain as following:

# Python toolchain
python = use_extension("@rules_python//python/extensions:python.bzl", "python")
python.toolchain(
    configure_coverage_tool = False,
    ignore_root_user_error = True,
    python_version = "3.11",
)

The python version must match the python version shown in the error trace, which in my case was 3.11.

When rules_python have been configured, the error goes away and the build completes.

In practices, this buys some time until the official Bazelmod rules arrive.

Also, I want to point out that the official migration guide is actually one of the better examples of Bazel documentation
and clearly shows that somebody thought this through and came up with a sensible solution to migrate larger projects step by step.

https://bazel.build/external/migration

[sluongng]

@marvin-hansen Hi Marvin.

Yes, the current hybrid mode should unblock you for now.

Me and @fmeum have been discussing internally how to convert BuildBuddy Toolchains to BzlMod. We sent #27 as a POC, but as you discovered, the current UX is not very nice and we want to make it a bit more sane so that our users would not have to switch back and forth between different config knobs. We will be resuming the work on this PR soon. I will update this issue when we have more updates to share.

The rules_python issue is a separate issue, not related to BuildBuddy Toolchains, but I'm glad that you were able to find a solution for it. If you are using BuildBuddy Workflows, you could update your user via this config https://www.buildbuddy.io/docs/workflows-config#action. Feel free to ask questions in our community Slack about this 🤗

[marvin-hansen]

Thanks for the update. I appreciate the detailed elaboration. I'm good for now, my Bazelmod config plus hybrid is running and humming on BuildBuddy. It's once more a confirmation that I made the right choice to build on BuildBuddy since stuff just works. Also, it's sensible to give the new Bazelmod design a bit more time. In the meantime, would be great to add the hybrid workaround in the Readme so people have a working stopgap until things are ready to go. Thank you for your work!

…

On Thu, Jun 13, 2024 at 5:07 PM Son Luong Ngoc ***@***.***> wrote: @marvin-hansen <https://github.com/marvin-hansen> Hi Marvin. Yes, the current hybrid mode should unblock you for now. Me and @fmeum <https://github.com/fmeum> have been discussing internally how to convert BuildBuddy Toolchains to BzlMod. We sent #27 <#27> as a POC, but as you discovered, the current UX is not very nice and we want to make it a bit more sane so that our users would not have to switch back and forth between different config knobs. We will be resuming the work on this PR soon. I will update this issue when we have more updates to share. The rules_python issue is a separate issue, not related to BuildBuddy Toolchains, but I'm glad that you were able to find a solution for it. If you are using BuildBuddy Workflows, you could update your user via this config https://www.buildbuddy.io/docs/workflows-config#action. Feel free to ask questions in our community Slack about this 🤗 — Reply to this email directly, view it on GitHub <#18 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFYR7XGW775IDUQYDJ5WY73ZHFOORAVCNFSM6AAAAABJHVAN3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVGA3TCMJXHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aherrmann]

I've been using the WORKSPACE.bzlmod hybrid setup up to now. But, I'm starting to see issues when trying to update other dependencies, e.g. rules_cc and protobuf. Perhaps not directly related to BB-toolchain, but to the MODULE.bazel/WORKSPACE.bzlmod mix.

Either way, I've tried to install BB-toolchain through bzlmod using archive_override. It seems to be working for Bazel builds with remote execution enabled. But, local builds, where I don't enable remote execution, stop working. I think the reason is that BB-toolchain always registers the exec-platforms and toolchains - under WORKSPACE I had only enabled them with remote execution enabled via command-line flags (see --config remote here).

I looked into the config options in the bzlmod example, but didn't find anything about enabling/disabling remote execution. Have you looked into ways to make the remote exec-platform and toolchains optional?

[marvin-hansen]

Is there a plan to publish the Bzlmod rules to BCR / https://github.com/bazelbuild/bazel-central-registry?

As of now, there seems to be nothing published yet.

[sluongng]

@aherrmann your observation is correct. I tested it out with buildbuddy-io/buildbuddy#7866 (comment) and wrote a lengthy internal note about the issue. The summary is that most of the open source rules don't work well when there are multiple exec platforms registered:

• Rules_go will use the wrong toolchain to cross-compilation remotely (i.e. using arm64 toolchain to produce an x86 stdlib)

• rules_swc will use the wrong toolchain as well as they are not declared with target_compatible_with.

• Rules_nodejs and @npm//@bazel/typescript (both deprecated but used by us) does not use toolchain/platform, thus wrong tool will be used constantly.

My conclusion was that registering multiple exec platforms is do able, but not worth our effort currently. So I will be yanking it out of our MODULE.bazel file shortly. If you want to set up your repo with multiple exec platforms registered statically, I can offer some help.

For now, folks should strongly rely on --extra_toolchains= flag to only register the needed exec platform(s).

[sluongng]

@marvin-hansen Getting this into the registry has been on my list of priorities since last week, but there were some other users' queries that pulled my attention away. Let me see if I can get it done this week 🤞

[marvin-hansen]

@sluongng Thank you for the update.
No rush, given that there are quite some ongoing obstacles w.r.t. to multiple exec platforms, I guess it makes sense to focus on these and other issues before the BCR release. Once its in the BCR and people are switching, more reports will roll in so having stuff sorted out beforehand makes sense to me.

Anyways, good work so far!

[aherrmann]

@sluongng Thank you for the quick response!

My conclusion was that registering multiple exec platforms is do able, but not worth our effort currently. So I will be yanking it out of our MODULE.bazel file shortly.

That sounds good! Let me know when you have that change up on GitHub. For now I've found a work-around by setting the execution platform explicitly in both the remote-execution and local build cases, see changes here. But, I'd prefer not to require extra configuration for the local build. So, yanking the default platform registrations sounds preferable.

[sluongng]

96323fd removed the static registration of exec platforms in the module.

@aherrmann could you please give the new version a test? I will look into the BCR release next.

[aherrmann]

@sluongng Thank you! I've tested it as part of aherrmann/rules_zig#408 and can confirm that local builds now work again without the need to explicitly register the host platform. Remote builds continue to work as intended.

[marvin-hansen]

I tried to use the new Bzlmod config, but bumped into an error:

In my module, I define:

bazel_dep(name = "toolchains_buildbuddy", dev_dependency = True)
git_override(
    module_name = "toolchains_buildbuddy",
    commit = "ffd296b7a9821174cdb2188d1373fd262cacb09d",
    remote = "https://github.com/buildbuddy-io/buildbuddy-toolchain",
)

buildbuddy = use_extension("@toolchains_buildbuddy//:extensions.bzl", "buildbuddy", dev_dependency = True,)

use_repo(buildbuddy, "buildbuddy_toolchain")

However, when I run a build, I get the following error:

bazel build //...
WARNING: Target pattern parsing failed.
ERROR: Skipping '//...': error loading package under directory 
'': error loading package 'build/platforms': Unable to find package for 
@@[unknown repo 'io_buildbuddy_buildbuddy_toolchain' requested from @@]//:rules.bzl: The repository '@@[unknown repo 'io_buildbuddy_buildbuddy_toolchain' requested from @@]' could not be resolved: No repository visible as '@io_buildbuddy_buildbuddy_toolchain' from main repository.
ERROR: error loading package under directory '': error loading package 'build/platforms': Unable to find package for @@[unknown repo 'io_buildbuddy_buildbuddy_toolchain' requested from @@]//:rules.bzl: The repository '@@[unknown repo 'io_buildbuddy_buildbuddy_toolchain' requested from @@]' could not be resolved: No repository visible as '@io_buildbuddy_buildbuddy_toolchain' from main repository.

Is there anything else I have to configure?

[sluongng]

The repo name under bzlmod should be @toolchains_buildbuddy

buildbuddy-toolchain/examples/bzlmod/.bazelrc

Lines 50 to 51 in 96323fd

	common:remote-linux --platforms=@toolchains_buildbuddy//platforms:linux_x86_64
	common:remote-linux --extra_execution_platforms=@toolchains_buildbuddy//platforms:linux_x86_64

So if you are moving from WORKSPACE -> bzlmod setup, you would want to (a) make sure that your WORKSPACE loads are removed and (b) replace all references to io_buildbuddy_buildbuddy_toolchain (including under .bazelrc files).

[marvin-hansen]

@sluongng Thank you, that did the trick.

The new Bzlmod format is simply amazing and lightyears better than the old workspace format.

It's literally just 3 lines and updating all references :

buildbuddy = use_extension("@toolchains_buildbuddy//:extensions.bzl", "buildbuddy", dev_dependency = True)
buildbuddy.platform(container_image = "docker://ghcr.io/my/custom/image:latest")
use_repo(buildbuddy, "buildbuddy_toolchain")

Good job on designing the rules.