https://pantsbuild.org/ logo
Join Slack
Powered by
Ran into an interesting issue in CI on `2.170.rc1`...
# general
r
Ran into an interesting issue in CI on `2.170.rc1`: a PR was doing a code refactor and pants was failing with 
pants.backend.python.dependency_inference.rules.UnownedDependencyError: Pants cannot infer owners for the following imports in the target
. However, there was no issue with this file/dependencies just simply renaming some files. Upon more investigate we discovered it's actually the pants cache causing this error. Generating a new cache from the branch or disabling it fixed the error. I'm going to see if I can create minimal repro for this issue but wanted to report here first as the behavior is not expected.
c
hmm, if pants were caching dependency inference results from a file that might be hard to reproduce. But also renaming the files should have caused the imports to change, so that should have caused pants to recompute the dependencies. I'm imagining you have something like file1.py:
Copy code
import file0
and then you renamed file0.py -> file2.py. And then it was saying that in file1.py it can't find the owner of file0 ?
r
well that's the thing no imports are acutally broken. Usually I rely on pants to find broken imports like this but this time 100% a false positive
even weirder, I just discover it only impacts relative imports
oh maybe this has something to do with the rust parser I think I recall a patch for relative imports
but still weird to see nuking the cache fixes the issue, ideally we would not do that
c
ohhh, hmm. that's interesting. I wonder if we store the resolved form of the relative import in some way. if you can get a repro, you can dump the dependency inference intermediate results with the python-dump-source-analysis goal (the analysis-flavor argument might help) https://www.pantsbuild.org/docs/reference-python-dump-source-analysis
👍 1
you'll probably need to enable the 
pants.backend.experimental.python
backend
r
I will try to repo in a smaller repo I'd imagine we can repro this pretty easily
but yeah changing all the relative import to absolute imports fixes the error. So we atleast don't need to nuke the cache
just a thought; we recently enabled 
ambiguity_resolution = "by_source_root"
so I wonder if a combination of these settings tripped up pants
I reproduced it
I'll open a formal issue but let document how to repro here first
b
Is this all within the same Pants version?
r
yeah all with same pants version did not test other version yet
b
OK, there's a "known bug" about changing Pants versions
r
but the original PR was not changing a version, simply renaming files. It just happened that the files had relative imports and pants is referring the old relocated file and not the new one.
👍 1
b
Gotcha, yeah tag me on the issue
r
You can easily reproduce this by having a repo with all relative imports. Change the source root and then 💥
I only got one case of relocated files causing this error, it seems to have to happenin a specfic order. Like run pants dep infer, relocate file with relative import an then run dep inference again and pants will say the owner of this file can't be found but pointing to the old location
pushed an example repo here https://github.com/njgrisafi/pants-example/tree/example-dep-inf-issue To repro similar behavior (first checkout repo / branch): 1. Run dependency inference 
./pants peek :: >> /dev/null
2. Remove 
[source]
section from pants.toml 3. Run dependency inference 
./pants peek :: >> /dev/null
You should see an error like
Copy code
UnownedDependencyError: Pants cannot infer owners for the following imports in the target app/app.py:

  * app.module_1.example (line: 1)
to note, the dev didn't change any pants setting within our org. This is just the easy way to get pants into that state where relative imports are not mapping to correct sources
b
Can you turn this into an issue?
r
for sure will raise an issue, jsut wanted to make sure we had a good way to repro this
oh man even weirder. Running with 
pantsd
totally fine, disabling pantsd falls back into that loop (writting issue now just formalizing repro steps)
See the 
Simple reproduction
section in the issue description. I created two branches with changes that should trigger the issue. Follow the steps and should be able to repro on your machine
heads up, if you already tried reproduction I just pushed a change. Please pull and try again. Will produce always produce the error now
Open in Slack
PreviousNext
Powered by