wanted: bazelbuild/buildtools

[uhthomas]

Module location

https://github.com/bazelbuild/buildtools

Link to bzlmod issue in the module's repository

https://github.com/bazelbuild/buildtools/issues/1124

Any other context to provide?

No response

Fund our work

• [ ] Sponsor our community's open source work by donating a feature bounty

[fmeum]

It is available via go_deps, but I agree that it should probably be available as a module. Once it is, we may want to forbid its use via go_deps to prevent version skew.

[alexeagle]

I'm not clear why this should be a Bazel Module. Why is this different from any other Go library? Are there any bazel rules or starlark modules to be loaded from it?

[jsharpe]

There are buildifier rules:

load("@com_github_bazelbuild_buildtools//buildifier:def.bzl", "buildifier")

buildifier(
    name = "buildifier",
)

[AttilaTheFun]

@alexeagle I found this issue through the linked buildtools ticket. Trying to use buildifier from a modular Bazel project is a bit of a hassle and having a module here would be a great help. It is useful for non-go projects, and I'd prefer that developers don't have to install Go themselves to run buildifier. (If Bazel installs it internally through rules_go that's fine.)

[fmeum]

@AttilaTheFun Even as a module buildtools would still not contain a precompiled version of buildifier. You might be interested in the buildifier_prebuilt module instead.

[AttilaTheFun]

@fmeum I don’t mind building from source. It would be cached most of the time.

[limdor]

@fmeum I would also expect to be built from source like any other module. I also think it should have it's own module, if you see the use case that @jsharpe posted, as a user you should not care if this is implemented using go or not. It does not make sense for a none go project to have to register go toolchains on your own when you only want to run the buildifier rule.

[fmeum]

We do have rules_go support for having a Bazel module be a Go module, so there is no real technical blocker or potential source of linker errors.

However, buildtools currently uses a tag scheme that is incompatible with the Go module release process: it only has tags of the form 6.4.0, not v6.4.0. Even if it did, Go considers different major versions to be entirely distinct dependencies, so continuing this version scheme would result in headaches.

@vladmos We had a similar discussion a while ago. Would it be feasible for buildtools to adopt the version scheme v1.X.Y, where X is aligned with the current major version of Bazel?