Skip to content
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

Merged
merged 2 commits into from Sep 10, 2022

Conversation

tdyas
Copy link
Contributor

@tdyas tdyas commented Sep 8, 2022

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 #13114.

[ci skip-rust]

Tom Dyas added 2 commits September 8, 2022 12:40
…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]
@tdyas tdyas added the category:bugfix Bug fixes for released features label Sep 8, 2022
@tdyas tdyas requested a review from stuhood September 8, 2022 16:48
@tdyas
Copy link
Contributor Author

tdyas commented Sep 8, 2022

The cherry pick was not clean due to the @union changes for environments. Otherwise applied cleanly.

@@ -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:
Copy link
Contributor Author

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?

Copy link
Sponsor Member

@stuhood stuhood left a 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.

@tdyas
Copy link
Contributor Author

tdyas commented Sep 10, 2022

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 register_plugin_field.

@tdyas tdyas merged commit 08ef336 into pantsbuild:2.14.x Sep 10, 2022
@tdyas tdyas deleted the cp_multiple_go_mod branch September 10, 2022 04:24
tdyas pushed a commit that referenced this pull request Sep 19, 2022
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]
tdyas pushed a commit to tdyas/pants that referenced this pull request Sep 19, 2022
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]
tdyas pushed a commit that referenced this pull request Sep 19, 2022
)

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]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:bugfix Bug fixes for released features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants