Deprecate "Secondary Ownership" semantics #18737
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently only 3 targets have "secondary owners" fields:
pex_binary
python_awslambda
(this assumes the filename is.py
Doh!)python_google_cloud_function
(this assumes the filename is.py
Doh!)The secondary ownership ability stems from wanting to use a goal by referring to the file (which presumably the "primary" owner doesn't support the goal). E.g.
package
ing a Python file packages the relevant PEX/Lambda/etc....However, it is a bit short-sighted:
pex_binary
(secondary) and apython_source
(primary). If multiple PEX binaries exist for a single source:run
andpaths
error on ambiguity and give unhelpful messages (saying that the filename was ambiguous, and then listing the filename as a valid address)So marking for deprecation and removal. Users can find the owners of the files from the specs and pipe that into the relevant goal. (If someone wants, we can add a new goal/flag to aid with this)