A fork in the bzlmod migration

[Filip Filmar]

Hi all. Looking for advice on a bzlmod migration dilemma.

I migrated my repo to bzlmod, and defined a dependency repo via an extension:

bazel_rules_bid_extension = use_extension(
    "@bazel_rules_bid//:extensions.bzl", "bazel_rules_bid_extension")
use_repo(bazel_rules_bid_extension, "gotopt2")

The gotopt2 repo is really “just” a released binary which I wanted to unpack and make available to my repository as a tool. Since it’s a binary only, it seemed excessive to define a registry entry for it.

But, now, I have to lug the extension and this bazel_dep to all downstream users, lest bazel complains that the repo gotopt2 used by my_repo is not defined.

So my question is this: should I expect to be defining registry entries for trivial repos that contain just one file? It seems a bit excessive for “just” a binary.

On the flip side, not defining a registry entry means I now have to lug this extension everywhere I want to use the repo, instead of benefiting from the automatic dep resolution.

What is the correct thing to do? Am I missing a third option?

Thank you,
F

[Allan Clark]

Have you considered the rules_multitool resource? It allows a json lock file to define the various of binaries as toolchains.

Take a look at the minimal example at GitHub.com/chickenandpork/example_multitool .. your use of gotopt2 is just one architecture, this may feel like overkill for “just one binary”, but it works and it’s very little to maintain.

Allan

[Filip Filmar]

On Fri, Mar 14, 2025 at 5:04 AM Allan Clark chicken...@gmail.com wrote:

Have you considered the rules_multitool resource? It allows a json lock file to define the various of binaries as toolchains.

Take a look at the minimal example at GitHub.com/chickenandpork/example_multitool .. your use of gotopt2 is just one architecture, this may feel like overkill for “just one binary”, but it works and it’s very little to maintain.

Ooh, thank you for a dedicated example at https://github.com/chickenandpork/example_multitool. It’s definitely an improvement over rolling a one-off extension for each binary. To answer your question I didn’t consider rules_multitool for the simple reason I didn’t know it existed.

But, do I see correctly that while the approach is more general than mine, you still need to lug the declaration use_extension around everywhere downstream? Or is there some additional magic that I’m not noticing which handles that?

F

[Filip Filmar]

It occurred to me today that "a binary that you lug around so you can apply it to source code" is, in fact, the definition of a toolchain component.  So, I guess it makes sense to register such a binary at every downstream use. I might merge the multitool example when I feel like practicing, since I like how general it is. I don't do much multiplatform building in personal stuff, so it's not essential to me, though it was instructive. But if someone finds use for that and wants to contribute, that's cool.

Thanks,

F

[Xudong Yang]

> But, now, I have to lug the extension and this bazel_dep to all downstream users, lest bazel complains that the repo gotopt2 used by my_repo is not defined.

You shouldn't need to do this unless your downstream users directly refer to `@gotopt2//:something`. If your module provides a rule or macro or whatever that refers to `@gotopt2//:something`, and your downstream users just use what you provide, then it's only your module that requires visibility into `@gotopt2`.

"  YÁNG Xùdōng (杨旭东)

#  SURNAME Givenname

=  Software Engineer

@  Google New York

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bazel-discuss/CAKaOXihJg%2Bx0dTmaxQ80O_nGCHm-D5%2B2puT%2BvhomV657RhfE2g%40mail.gmail.com.

[Filip Filmar]

On Mon, Mar 17, 2025 at 8:28 PM Xudong Yang <w...@google.com> wrote:

> But, now, I have to lug the extension and this bazel_dep to all downstream users, lest bazel complains that the repo gotopt2 used by my_repo is not defined.

You shouldn't need to do this unless your downstream users directly refer to `@gotopt2//:something`. If your module provides a rule or macro or whatever that refers to `@gotopt2//:something`, and your downstream users just use what you provide, then it's only your module that requires visibility into `@gotopt2`.

Indeed, the rules I provided do have direct references. I'll see if I can restructure this so it's less onerous.

Thanks, all, for your advice!

F