Fabian Meumertzheim
Fabian Meumertzheim
@vladmos Friendly ping
@vladmos Friendly ping
I think we want new buildozer syntax here, maybe `//some/pkg:some_attr=foo`?
That feels quite magic and ties Buildozer to an implementation detail of Bazel (canonical repository names). It also doesn't allow specifying extension tags such as `go_deps.gazelle_override`, which can be combined...
> are you suggesting something like `buildozer "set some_attr foo" //MODULE.bazel:path=golang.org/x/tools` Yes, exactly that, where `:name=foo` would match the current behavior. There could be other syntax for this, but the...
I also ran into this. You can either use `:%` to specify a particular `archive_override` or temporarily rename `module_name` to `name` on `:%archive_override`, then reference it like a regular rule,...
@vladmos They are picked up automatically as new tags are added and requested by users. That is also why the format of the tag (`v1.2.3` instead of `1.2.3`) is important.
@vladmos It should, but I missed an important point: Go modules tend to not increase their major semver version that often and when they do, their import path needs to...
@tyler-french I have never used it myself, how would this look like? I just noticed that Bazel CI doesn't seem to be prepared to handle the semantic versioning format: https://buildkite.com/bazel/stardoc/builds/866#0187c31b-4c54-45ac-9ea2-3513e38731ec...