Hi all, we have some optional imports (

with suppress(...): import x

) in our codebase that are local/internal packages, which are not available in any repository. During pants test, we get warnings in the form

Pants cannot infer owners for the following imports in the target a/b/c.py: x

. We have disabled the warnings using

# pants: no-infer-dep

in the code but would like to do it centrally and are trying the

!{bad_address}

syntax as shown here. However, since

x

is not in the known dependencies, it does not work. Any ideas how to make it work globally instead of annotating every import?

FWIW Pants already suppresses those warnings inside a

try/except ImportError

block

why trickier? https://docs.python.org/3/library/ast.html?highlight=ast#ast.With

import contextlib

vs

from contextlib import suppress

ah, that just adds a few permutations to look for, right.. the logic would still be pretty straight forward.

At some point I wonder if using a Python parsing library we can build on would be easier... libCST maybe?

Hi, thanks for the answers, I dug in the code and see it now. For the moment we could change

with suppress()

to

try/except

since that is caught and maybe try to create a PR in pants for adding

suppress

support.

At the very least, feel free to file an issue

By the way, I was experimenting with making the script for dependency parsing configurable through a pants plugin. It's not needed just for

suppress

, I'm just trying to gain experience and maybe cover some other corner cases. What would be the recommended way to do it? Somehow overriding this rule would do the job, but I didn't find a way to do it. Defining my own equivalent rule did not work (it's ambiguous for the rule engine) and using a union as described in the documentation for custom python_artifact kwargs is not possible, because the current rule is not declared as

@union

. Would I have to start from some higher level classes like

InferDependenciesRequest

or

PythonInferSubsystem

and wrap or derive from every class inbetween to do this?

In this case, you can't really augment the rexisting rules, you'd just add another dependency inference rule which does something insanely similar. Hmm I looked but we don't have a guide for this 😞