https://pantsbuild.org/ logo
Join Slack
Powered by
Stu and I are wondering what makes sense for how `...
# development
h
Stu and I are wondering what makes sense for how 
--changed-since
should handle deleted files in Pants 2.0. Currently, we match the original owning target, whereas the rest of 
--changed-since
will only ever use generated subtargets (1 target per source file) https://github.com/pantsbuild/pants/pull/10511 doesn’t behave great with that model. It changes it so that we always generate a subtarget if the original target has sources. This means that a deleted file would result in every possible generated subtarget being used from the original owning target. Say the original target has 5 source files, and you deleted one; we’ll run on those 4 still-existing files. I don’t think that behavior makes a ton of sense in a file-centric world? Maybe we no longer cause a deleted file to trigger Pants to run?
cc @happy-kitchen-89482 @witty-crayon-22786
f
You should trigger on deleted files. Imagine that one of the four remaining files referenced code in the deleted file. They should be rebuilt and generate an error for the missing code.
👍 1
w
@fast-nail-55400: they will already because of either 1) inference, 2) explicit deps.
but as i say that, i think that it’s less a question of “do we find something depending on the deleted file”, and more a question of: “what is the root/leaf” that we consider to have matched. @hundreds-father-404: it might be that we should always scan for dependees if we didn’t find any roots/leaves…?
ie: if no owning targets, scan
so, yes: sorry Tom. you need to run, for sure. but i don’t think it matters which original target owned the deleted file… it just matters that you look at all the possible dependees regardless of whether you found a match
double sorry: i oversimplified here. because there are cases where no dependencies will be declared on a particular file (say if the target was a 
resources
target) this is definitely still a thing.
Open in Slack
PreviousNext
Powered by