Fabian Meumertzheim
Fabian Meumertzheim
@katre
Not yet, but I've been working on this over at https://github.com/bazel-contrib/rules_go/pull/4106. It's a bit more difficult for Go as there are two relevant versions, the SDK and the language version.
https://github.com/fmeum/ics2gcal/pull/10 was almost there but went stale. I haven't worked on extensions in a while, so if you were to pick it up, that would be very welcome!
I think that the default locale with no env vars set is always C on Linux and that's what happens in the sandbox, so I expect this problem to be...
Since `--action_env` requires explicit configuration and makes it more easy to screw up cache performance, I would prefer a more explicit fix if we can find one.
Cc @AlessandroPatti for the wrapper
If your project uses WORKSPACE, pretty much any dependency will expect rules_go's repo to be called `io_bazel_rules_go`. If you use Bzlmod, the `repo_name` that `aspect_bazel_lib` uses internally shouldn't matter. What...
I don't think we should do anything here. It would break WORKSPACE users and Bzlmod users already have the freedom to pick their own repo_names.
I could very well see this live in Gazelle. Do you think that any of the two recent proposals https://github.com/bazel-contrib/bazel-gazelle/issues/1891 and https://github.com/bazel-contrib/bazel-gazelle/issues/1907 could substantially improve the situation for your large...
> Yeah, I think that sounds like a useful feature to maintain, than changing the existing behavior of non-mergeable attributes. @fmeum @jayconrod What do you think? I agree that making...