I am surprised to see what `./pants dependencies` ...
# general
f
I am surprised to see what
./pants dependencies
does when dependency inference is disabled and enabled 🧵
1
on https://github.com/pantsbuild/example-python
Copy code
cp helloworld/translator/translator_test.py helloworld/translator/translator_another_test.py
Copy code
$ ./pants dependencies helloworld/translator/translator_test.py                                 

//:reqs#pytest
helloworld/translator/translator.py:lib

$ PANTS_PYTHON_INFER_IMPORTS=False ./pants dependencies helloworld/translator/translator_test.py

helloworld/translator/translator_another_test.py:tests
Why does Pants report
translator_another_test.py
to be a dependency of
helloworld/translator/translator_test.py
? It's clearly not:
Copy code
$ ./pants paths --to=helloworld/translator/translator_test.py --from=helloworld/translator/translator_another_test.py
[]
It must have something to do with the fact that they are part of the same target, but I can't find the reasoning behind this behavior when dependency inference is disabled.
that is, with dep inference off, there’s an implicit assumption that all files in the same module have a dependency on each other.
f
wow
okay this may make sense for
python_sources
, but for
python_tests
? 😕
c
True, as tests are executed one by one, probably doesn’t make sense there.. cc @hundreds-father-404 thoughts?
h
hm yeah probably doesn't make sense for tests
but generally it'd be better to have an option to disable this. it should be legal to have your own dep inference implementation and ignore our builtin one
💯 1
this behavior destroys effective caching, even tho it's a good default if you have no dep inference at all
but generally it'd be better to have an option to disable this.
advanced option on python-infer. In fact I thought we added it, but couldn't find it. Someone wanted it 2 months ago
f
amazing, thank you for giving it a thought. Shall I file a GH issue with the motivation and command examples to illustrate the problem?
Copy code
$ ./pants --changed-since=HEAD --changed-dependees=direct \
    --filter-target-type=python_test list
The use case is that if there have been changes to a test module, this command would list all Python test modules in the same
python_tests
target which is unnecessary
👍 1
h
that is, with dep inference off, there’s an implicit assumption that all files in the same module have a dependency on each other.
Is it “all files in the same module” or “all files in the same target generator”?
h
same target generator
c
☝️ yep, I was inaccurate in that statement