Fabian Meumertzheim
Fabian Meumertzheim
This has to wait for another Gazelle release.
The bazel-lib function operates on Starlark `File` functions representing build artifacts tracked by Bazel, which have no equivalent in Go (or any other language). What is your use case?
I agree that runfiles paths would make sense as imports. But couldn't you just pass a mapping from full paths to runfiles paths into the first action, using the existing...
Yes, that's true, but at least this can be handled quite nicely with `ctx.actions.args` `map_each` on the Starlark side. Going from full path to runfiles path can be pretty tricky...
It's only a 2 line function because Bazel knows more about a given file than just its `path` though. I tried before but unfortunately building a general purpose `rlocation_path` field...
I also support the `--legacy_external_runfiles` flip. I have submitted a PR to flip it for Bazel tests, which caught an actual bug and prevents further regressions: https://github.com/bazelbuild/bazel/pull/20680. I can start...
@rharter A bit of context: This came up over at [Bazel](https://github.com/bazelbuild/bazel) while building some kind of generic package manager that heavily relies on auto-value-gson to generate its lockfile. Since we...
I would say no, let's change the behavior if the user explicitly requests it in this way. @linzhp Any concerns?
Some tests are failing due to differing repository names. I can look into this when there is general consensus on the approach. I'm also happy to make this new behavior...