https://pantsbuild.org/ logo
Join Slack
Powered by
Wondering about behaviors I should expect around r...
# general
f
Wondering about behaviors I should expect around removing dependencies and transitive dependent detection: Right now (Pants 2.13) if I remove 
example/lib.py
I would expect files that import that like 
example/app.py
to be an affected transitive dependent, but it doesn't seem like this is the case. Is there a way to enable this behavior if it exists? Or does that imply scanning deps on two different versions of the worktree?
❗ 1
Bumping this question around dep inference on deletion. Do we have a way of including former dependees in the scope of affected files with 
--changed-dependees=transitive
?
e
Nope. Your guess was correct, that would requiring Pants going back in time (using git), doing things, then comparing to the present. It currently just gets the changed file list from the commit range implied.
➕ 1
Clearly you can script the requirement above outside of Pants. Maybe not bad for CI. Less good for devs.
f
I know it's a bit complicated to deal with... but this feels like a bug? I feel like I want to rely on Pants to do the right thing for dep inference, but this is an area where it can't help me. The obvious solution to script this with a worktree seems pretty inefficient to run during dep inference
Copy code
wt=$(mktemp -d)
git worktree add -f $wt $changed_since_ref > /dev/null
cd $wt
./pants dependees --transitive ${deleted_files[@]}
cd -
git worktree remove $wt > /dev/null
is the best i can come up with off the top of my head
w
see https://github.com/pantsbuild/pants/issues/14975 and https://github.com/pantsbuild/pants/issues/17512 on this topic: this is a good reason to have 
--unowned-dependency-behavior=error
🙏🏻 1
👀 1
f
Thanks. I felt some deja vu looking at this again. Thanks for pointing me to the issues
okay we've got some work to get there since we're not inferring 3rd party deps (we're about to add RPM inference of python packages to enable this), but that does look like a decent ticket for 95% of my cases
I think combined with 
unmatched_build_file_globs = error
it might cover 99% but I can come up with an edge case: removing a conftest.py in a test folder that contains other sources that match the 
sources
globs in the 
python_test_utils
target (like 
blah_tests.pyi
or something custom). Because of the other sources, 
unmatched_build_file_globs
won't trigger, and because nothing explicitly imports conftest, 
unowned_dependency_behavior
won't catch that. Otherwise I think you're right that those two options do it. But this seems to be a consequence of the kinda magical behavior of 
conftests
5 Views
Open in Slack
PreviousNext
Powered by