Rename FilesSources
and split target into target generator vs. atom target
#13190
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.
Part of #12954 and the proposal at https://docs.google.com/document/d/1HpJn2jTWf5sKob6zhe4SqHZ7KWBlX4a6OJOwnuw-IHo/edit.
End functionality is the same, but we're now safe in followups to expose
files
vs.file
targets, where the former has anoverrides
field.This brings to light an issue explored in #13086: when looking at direct dependencies, should you replace the target generator with its generated targets? Here, we need to for the
archive(files=
) andrelocated_files(files_targets=)
fields to work when you put an address for afiles
target rather than afile
target. As the author of those two targets, I did not realize this nuance, even though we had file targets in Pants 2.0+ and this dynamic still existed. This is subtle and awkward, but I think valuable to bring to light something we need to figure out vs. hiding it.[ci skip-rust]
[ci skip-build-wheels]