feat(gazelle): Add "include_dep" Python comment annotation#1863
feat(gazelle): Add "include_dep" Python comment annotation#1863f0rmiga merged 27 commits intobazel-contrib:mainfrom
Conversation
|
Still TODO:
|
| for i, v := range s.Values() { | ||
| dedupe[i] = fmt.Sprint(v) | ||
| } | ||
| return dedupe |
There was a problem hiding this comment.
Coming from python, this function feels icky to me. I'd really like to be able to just do
allAnnotations.includeDep = list(set(allAnnotations.includeDep))above but I couldn't figure out how to do so. The issue is related to types: the treeset.Values() is type []interface{}, treeset.NewWith's values arg is interface{}, but includeDep is []string. From what I could find, there's no easy way to "cast" []string to []interface{} and back.
If you have any suggestions on how to clean things up, I'd be happy to hear them. Otherwise no reply is needed.
There was a problem hiding this comment.
I've been meaning to pick up https://github.com/f0rmiga/datanalgo and add the missing data structures using generics. I can try to resurrect that, which would be ideal to use with the Gazelle extension.
gazelle/python/parser.go
Outdated
| } | ||
|
|
||
| return modules, mainModules, nil | ||
| allAnnotations.includeDep = removeDupesFromStringTreeSetSlice(allAnnotations.includeDep) |
There was a problem hiding this comment.
Do we even want to remove duplicates here? We could just rely on the target builders to handle that.
| for k, v := range annotations.ignore { | ||
| allAnnotations.ignore[k] = v | ||
| } |
There was a problem hiding this comment.
annotations.ignore is not used in generate.go so we could leave this out if wanted. Thoughts? Leaving it out would mean that the returned allAnnotations is not representative of everything that was parsed.
gazelle/python/parser.go
Outdated
| // The parsed modules to be ignored by Gazelle. | ||
| ignore map[string]struct{} | ||
| // Labels that Gazelle should include as deps of the generated target. | ||
| includeDep []string |
There was a problem hiding this comment.
Should this be plural? Same elsewhere.
I originally went singular to be consistent with annotations.ignore.
There was a problem hiding this comment.
I'd make it plural because it is a list. I don't see a need to make ignore plural, though.
|
I think this is ready for review. Note that this might be a bit of a footgun. Users can add non-python targets to If that's deemed too big of risk, I'd be happy to discuss alternative solutions. |
|
Don't have time to look into this right now, but after reading your last comment, I am wondering if the right way to avoid the footgun would be to use the import path as an argument to the gazelle comment, but that is almost as a noop import statement using just python? Which puts us back to square 1. I'll think about this a little more. |
| This annotation accepts a comma-separated string of values. Values _must_ | ||
| be Python targets, but _no validation is done_. If a value is not a Python | ||
| target, building will result in an error saying: | ||
|
|
||
| ``` | ||
| <target> does not have mandatory providers: 'PyInfo' or 'CcInfo' or 'PyInfo'. | ||
| ``` | ||
|
|
||
| Adding non-Python targets to the generated target is a feature request being | ||
| tracked in [Issue #1865](https://github.com/bazelbuild/rules_python/issues/1865). |
There was a problem hiding this comment.
This is all fine, we can't save the world.
| @@ -0,0 +1,17 @@ | |||
| # Copyright 2023 The Bazel Authors. All rights reserved. | |||
There was a problem hiding this comment.
Could you please update all the new license headers you are adding?
| # Copyright 2023 The Bazel Authors. All rights reserved. | |
| # Copyright 2024 The Bazel Authors. All rights reserved. |
We are overthinking here. If the user gets to this point, the entire implementation will look wrong (the user code). |
Co-authored-by: Thulio Ferraz Assis <3149049+f0rmiga@users.noreply.github.com>
Co-authored-by: Thulio Ferraz Assis <3149049+f0rmiga@users.noreply.github.com>
dougthor42
left a comment
There was a problem hiding this comment.
I'll think about this a little more.
We are overthinking here. If the user gets to this point, the entire implementation will look wrong (the user code).
👍 we won't try to prevent the user from adding a non-python dependency.
gazelle/python/parser.go
Outdated
| // The parsed modules to be ignored by Gazelle. | ||
| ignore map[string]struct{} | ||
| // Labels that Gazelle should include as deps of the generated target. | ||
| includeDep []string |
| @@ -0,0 +1,17 @@ | |||
| # Copyright 2023 The Bazel Authors. All rights reserved. | |||
|
Thank you, @dougthor42! |
The annotation is `include_dep`, not `include_deps`. ```console $ # Before this PR: $ rg -F "include_deps" CHANGELOG.md 76:* (gazelle) Add a new annotation `include_deps`. Also add documentation for $ $ # After this PR, there are no more references to "include_deps" $ rg -F "include_deps" $ ```
Add a new Python comment annotation for Gazelle:
include_dep. Thisannotation accepts a comma-separated string of values. Values should
be targets names, but no validation is done.
The annotation can be added multiple times, and all values are combined
and de-duplicated.
For
python_generation_mode = "package", theinclude_depannotationsfound across all files included in the generated target.
The
parser.annotationsstruct is updated to include a newincludeDepfield, and
parser.parseis updated to return theannotationsstruct. Alltarget builders then add the resolved dependencies.
Fixes #1862.
Example:
will cause gazelle to generate: