Fabian Meumertzheim
Fabian Meumertzheim
The extension usage changed with https://github.com/bazelbuild/rules_python/commit/46537cf32f8bf722a6be805821cb2ee17d7b936a, but that change hasn't been released yet. @rickeylev @chrislovecnm
Thanks for the heads-up. Bazel's rules_go has adopted `go.mod` as the source of truth for dependency declarations with Bazel's new dependency management system Bzlmod (https://github.com/bazelbuild/rules_go/blob/master/docs/go/core/bzlmod.md#specifying-external-dependencies). We would thus be able...
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...
@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.
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...
@tyler-french I could see this living in `rules_go` and being implicitly invoked with `bazel run @rules_go//go mod tidy`, with an option to disable this. What do you think?
@grindlemire @iamricard I am still trying to make sure that this really does cover the problems people experience with `go mod tidy`. Could you maybe share reproducers for the exact...
@iamricard Just a small standalone sample git repo would be ideal. This can easily be turned into an integration test when the PR can address it.
@oliverlee Copying and modifying the generated file is the easiest approach I can think of. After you have confirmed your changes work, you can modify the file in a checkout...
The `apole_support`/`bazel_tools` toolchain situation is unfortunate, but we're trying to improve this for Bazel 8. Right now, there is nothing you can do to force this for the root module....