New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go: analyze imports paths by module to enable multiple go_mod targets (Cherry pick of #16386) #16799
Conversation
…pantsbuild#16386) The package mapping from import path to addresses (`ImportPathToPackages`) was global to the entire repository and not split by Go module. This prevented using multiple Go modules in a single repository. This PR solves the issue by introducing `GoImportPathMappingRequest` which allows the package mapping to be requested per module. That per-module mapping relies on a repository-wide mapping available as `AllGoModuleImportPathsMappings`. The `GoModuleImportPathsMappingsHook` union allows plugins to provide their own import path mappings. For example, this support is now used by the protobuf/go codegen backend to supply import paths from generated protobuf code, meaning that the Go backend is able to infer dependencies between Go code and protobuf code automatically. Fixes pantsbuild#13114. [ci skip-rust]
[ci skip-rust] [ci skip-build-wheels]
The cherry pick was not clean due to the |
@@ -1046,6 +1045,14 @@ def validate(self) -> None: | |||
"`TargetGenerator.moved_field`s, to avoid redundant graph edges." | |||
) | |||
|
|||
@classmethod | |||
def register_plugin_field(cls, field: Type[Field], *, copy_field: bool = False) -> UnionRule: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stuhood: Is this an okay API change to make via chery pick to a still alpha branch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming that all of this is backwards compatible, it seems fine to me.
It should be. I just wanted a second opinion on the choice of keyword argument with default as being backwards compatible for |
As reported on Slack, after #16799, help for targets with plugin fields was listing those plugin fields multiple times. Remove the override of `register_plugin_field` on `TargetGenerator` since tests seems to pass without that code and the need to set the plugin field as a moved or copied field may be unnecessary if the field is registered on the generator and the generated target types. [ci skip-rust] [ci skip-build-wheels]
As reported on Slack, after pantsbuild#16799, help for targets with plugin fields was listing those plugin fields multiple times. Remove the override of `register_plugin_field` on `TargetGenerator` since tests seems to pass without that code and the need to set the plugin field as a moved or copied field may be unnecessary if the field is registered on the generator and the generated target types. [ci skip-rust] [ci skip-build-wheels]
) As reported on Slack, after #16799, help for targets with plugin fields was listing those plugin fields multiple times. Remove the override of `register_plugin_field` on `TargetGenerator` since tests seems to pass without that code and the need to set the plugin field as a moved or copied field may be unnecessary if the field is registered on the generator and the generated target types. [ci skip-rust] [ci skip-build-wheels]
The package mapping from import path to addresses (
ImportPathToPackages
) was global to the entire repository and not split by Go module. This prevented using multiple Go modules in a single repository. This PR solves the issue by introducingGoImportPathMappingRequest
which allows the package mapping to be requested per module.That per-module mapping relies on a repository-wide mapping available as
AllGoModuleImportPathsMappings
. TheGoModuleImportPathsMappingsHook
union allows plugins to provide their own import path mappings. For example, this support is now used by the protobuf/go codegen backend to supply import paths from generated protobuf code, meaning that the Go backend is able to infer dependencies between Go code and protobuf code automatically.Fixes #13114.
[ci skip-rust]