https://pantsbuild.org/ logo
#development
Title
# development
c

curved-television-6568

04/09/2021, 8:47 AM
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
Copy code
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?
h

hundreds-father-404

04/09/2021, 9:18 AM
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
c

curved-television-6568

04/09/2021, 9:22 AM
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.
h

happy-kitchen-89482

04/09/2021, 5:11 PM
Yeah, an (optional) warning might be a great idea
"cannot find where this dep comes from, here is how to fix"
That's actually a great idea
❤️ 1
h

hundreds-father-404

04/09/2021, 5:12 PM
@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
?
h

happy-kitchen-89482

04/09/2021, 5:14 PM
I think for everything! It's a potential gotcha if we silently fail to resolve a dep
👍 1
We can say "here is an import we couldn't map back to anything we know about, you can fix by adding an appropriate 3rdparty dep or by providing an explicit dependency"
I mean, we obviously need to finesse the error message, but...
h

hundreds-father-404

04/09/2021, 5:19 PM
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
w

witty-crayon-22786

04/12/2021, 4:35 PM
how would you silence the warning?