Open kevinaud opened 1 year ago
For #2 you want something like:
# gazelle:map_kind py_test pytest_test //my/rules:pytest.bzl
Unfortunately that overrides it in the current package and all subpackages (though you could override it back if you like), which means you can't use the same technique for #1. As a workaround you can just have Gazelle make the py_binary and then use cc_image
with binary=
(yes, it says cc but it works for any binary).
There's an upstream ticket talking about making different kinds of targets, but it's unfortunately not possible yet.
What @adzenith has suggested is the preferred way of providing overrides. Providing different kinds of targets should be a separate feature request so that we can look at the use cases more clearly.
I have also figured out that the GenerateRules function has access to the currently existing BUILD file. It's possible to search the existing rules (args.File.Rules
) to find out if there's, say, a py_image
target already containing the source we're looking at, and then tell Gazelle to create a rule of that type instead of making a new rule, which will result in Gazelle updating the deps of the existing rule in the BUILD file.
This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_python!
I don't think this is stale. This would be a great feature to have.
🚀 feature request
Relevant Rules
Gazelle Plugin
Description
There are two issues I'm running into: 1) Some of my binaries need to use
py_image
rather thanpy_binary
but gazelle can't manage deps forpy_image
. 2) I have a custom macro calledpytest_test
that I use for my tests that use pytest but Gazelle generates apy_test
target for those files. I have to manually ignore all of those files and then manually manage the target since thepy_test
rule can properly run them.Describe the solution you'd like
It would be great if there was a Gazelle annotation where, for the current scope, Gazelle could be configured to use a different rule for particular target types.
Describe alternatives you've considered
The only workaround I know of is to instruct Gazelle to ignore the files and then manage the build targets manually.