wanted: bazelbuild/buildtools

[uhthomas]

Module location

https://github.com/bazelbuild/buildtools

Link to bzlmod issue in the module's repository

bazelbuild/buildtools#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?

[limdor]

What is the status of this issue? Any other topics blocking it? I see in the tags that all latest tags use the v version https://github.com/bazelbuild/buildtools/tags
This starts becoming a more pressuring issue because in Bazel 8 by default the WORKSPACE file is disabled and then the only way to do it is with bzlmod.
For buildifier there is the version with prebuilts https://github.com/keith/buildifier-prebuilt but it is not working on Windows keith/buildifier-prebuilt#99
This means that starting with Bazel 8, Windows users will have no way to use the buildifier rules unless they reenable the WORKSPACE file and in Bazel 9 AFAIK the plan is to drop the WORKSPACE file support.

[fmeum]

The problem with versioning hasn't been resolved yet: While buildtools publishes vX.Y.Z style tags, those don't match the Go module path structure (everything would need to be in a vX subdirectory). We could go back to tags that don't start with a v, but then the BCR versions would look like 0.0.0-20191109021931-daa7c04131f5, which isn't exactly user friendly.

If we fix keith/buildifier-prebuilt#99, would that solve the issue for you? That does sound the easiest path forward.

[limdor]

To me that would be an acceptable solution. I'm not aware of a real use case where building from source would be important.
Right now my main concern is that the support of buildifier rules with bzlmod and Windows seems to be none existent when before bzlmod was supported.

[lamielle]

I've looked around for this as I'm exploring migration to bazel 8. I know freebsd isn't an officially supported platform, but due to the lack of freebsd binaries in buildifier-prebuilt I'm not able to go that route. So at this point it looks like compiling buildifier from source via a module extension (similar to the example here: https://github.com/grpc-ecosystem/grpc-gateway/blob/main/non_module_deps.bzl) is the approach I'll have to take for now until an official buildifier entry is added to the BCR.

I figured I'd drop that grpc-gateway example here in case others prefer to build from source and need a reference for how to accomplish it.

[mering]

@fmeum Does https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/bzlmod.md#depending-on-tools also work for buildifier?

[fmeum]

@fmeum Does https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/bzlmod.md#depending-on-tools also work for buildifier?

Yes, it should work for any Go main package. Please let me know if you run into issues.