Without syntax errors:

❯ ./pants dependencies helloworld/greet/greeting.py
//:reqs#setuptools
//:reqs#types-setuptools
helloworld/greet:translations
helloworld/translator/translator.py:lib

Adding a patch:

diff --git a/helloworld/greet/greeting.py b/helloworld/greet/greeting.py
index 6a5eb1a..79d18f9 100644
--- a/helloworld/greet/greeting.py
+++ b/helloworld/greet/greeting.py
@@ -10,6 +10,7 @@ import pkg_resources
 
 from helloworld.translator.translator import LanguageTranslator
 
+this.is.a.problem
 
 class Greeter:
     def __init__(
...

Pants only suggests dependencies on

__init__.py

files and target (as per the BUILD file):

❯ ./pants dependencies helloworld/greet/greeting.py 
helloworld/greet:translations

Is there a situation when you would want to proceed anyway ignore files with incorrect syntax? I've discovered this by accident when I noticed Pants wasn't reporting dependencies for a file that had many: I used

python.interpreter_constraints = ["==3.9.*", "==3.10.*"]

and Python 3.9 was used for dependency inference on a file that contained Python 3.10 syntax. I think this is a common situation enough (having mixed Python versions) so it perhaps deserves some thought.

Although it may be impossible in practice...

But anyway, re failing on unparseable code, I can see both sides on that. Having the build system itself (rather than an underlying tool) fail on a syntax error in your code seems very aggressive.

On the other hand, it can lead to a more confusing error later

without any indication that the representation is likely to be incomplete