cont. from <
# development
cont. from regarding @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:
Copy code
pex_binary(name="bin", entry_point="foo.qux.bin:main")
I don’t see that there is a
file in
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
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
"cannot find where this dep comes from, here is how to fix"
That's actually a great idea
❤️ 1
@happy-kitchen-89482 for every import in a Python file, or only these fields where we do dep inference like
, and (soon)
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...
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?