cont. from https://pantsbuild.slack.com/archives/CASMF8SJ1/p1617029155053700 regarding https://github.com/pantsbuild/pants/issues/11808 @hundreds-father-404 quick question, if while doing dependency inference, shouldn’t it be an error if we can’t resolve a dependency? Looking at this line in a test case: https://github.com/pantsbuild/pants/blob/bb3fa05d4b32512eb8674d6dbfacb5f07e1f8596/src/python/pants/backend/python/goals/setup_py_test.py#L159

pex_binary(name="bin", entry_point="foo.qux.bin:main")

I don’t see that there is a

bin.py

file in

foo.qux

for the test, and it is not listed in the assert either, so I feel like this should fail.. but seems like it is silently ignored?

Negative, a very important requirement for dep inference is that it never breaks your build. If we can't infer a dep, that is a recoverable issue and the user can address it by explicitly adding to the

dependencies

field Granted, there is a place for warnings, such as the new warning if we can't infer because it's ambiguous because >1 target owns the same module

Right, I can see we don’t want to break if the dep indeed exists (and we just don’t know about it), a warning seems like good middle ground then.

Yeah, an (optional) warning might be a great idea

@happy-kitchen-89482 for every import in a Python file, or only these fields where we do dep inference like

pex_binary.entry_point

,

python_awslambda.handler

, and (soon)

python_distribution.entry_points

?

I think for everything! It's a potential gotcha if we silently fail to resolve a dep

Yeah I think that makes sense. I would want to ensure our std-lib ignore logic is robust so that we're not complaining about std lib imports. But otherwise sounds sensible And could catch issues like that you are depending on a 3rd party requirement that happens to be a transitive dep, so the resolve works, but really you should have declared it as a top-level requirement and had a proper dependency

how would you silence the warning?