https://pantsbuild.org/ logo
Join Slack
Powered by
Any particular reason why we special case the depe...
# development
c
Any particular reason why we special case the dependency from a source to the BUILD file declaring the owning target? 🧵
As I’m looking into https://github.com/pantsbuild/pants/issues/19805 the issue is that the owning target is affected not only by the contents of the one BUILD file where it is declared, but also in case of defaults, any number of parent BUILD files.
I figure I can track where default values are declared, and pass these origins down to the relevant `TargetAdaptor`s, but then is the question how we want to expose it..?
I see two options a) keep the special handling, adding a notion of multiple BUILD file dependencies rather than just the one holding the target itself, or b) generalise the above so it goes into the regular dependencies of the target, which would make BUILD files show up in the list of dependencies along with other explicit and inferred deps.
opt b may have undesirable side-effects I’m not aware of, so I’m reluctant to go down that road.. but it feels more “correct”, in not hiding these dependencies.
esp. with defaults, would be nice to be able to introspect which BUILD files impacts the field values of a target using 
peek
, no?
h
I think @hundreds-father-404 may remember the issues around this
f
Why are BUILD files a dependency at all? I’d argue they are indeed special. I really wish we didn’t consider them as dependencies, especially for 
—changed
calculations, at least not at that granularity. Like, if we’re special casing things, it would be nice to treat BUILD files as a collection of sub-file dependencies consisting of the target metadata they define rather than any single dependency itself
I realize that having sub file target like behavior at all is a feature request, but it could be one that justifies special casing here
h
The idea is that we don't know what you changed about the metadata in the BUILD file. We can't from Git figure out if you changed only one target (generator) or multiple. The change in metadata may have impacted Pants caching. So the only safe conservative approach is to pessimisticly assume it's all impacted Actual Pants lmdb caching is more precise than this. This is only a workaround for 
--changed
which solely has access to Git state
f
That makes sense. However I regard any discrepancy between how 
--changed
and cache-based behavior works as a defect, because from the point-of-view of really large and hairy monorepos, running 
pants whatever ::
isn't realistic, since at some level just resolving deps for that takes up too much memory. I guess in that case I should make an issue for this. In theory we could actually checkout build files from the changed-since ref and compare them, but that might slow down the subsystem quite a bit
âž• 1
I played around with this at some point, when I was experimenting with the possibility of writing a subfile target python backend that used patches to try to figure out what top-level definitions in a python module changed. That turned out to be way too ambitious and complicated, but the idea of comparing refs is very possible
I may be overstating this though: reading old BUILD files is just 
git show $ref:$path
for every changed BUILD file, and that's easy. Then you'd need to load their metadata in ways that 1) doesn't actually load those targets, and 2) can handle potential changes in config, pants version, or plugin code, where the target definitions may be invalid or worse just incorrect
Open in Slack
PreviousNext
Powered by