https://pantsbuild.org/ logo
Join Slack
Powered by
So there's a nice `# pants: no-infer-dep` directiv...
# general
h
So there's a nice 
# pants: no-infer-dep
directive. Is there something like 
# pants: allow-missing-dep
?
✅ 1
h
To say “don’t worry if you can’t find a thing that provides this `import`“?
b
Not currently. But with a sufficient use-case sounds easy to add
c
pants dependency parsing will already flag weak imports (those in try/catch blocks) which will be ignored if missing. I think it would be simple enough to have a pragma flag imports as weak explicitly
h
Yeah, exactly like that. In a couple places, we have some try/except style imports that I'd like pants to try to infer if it can but be satisfied and carry on with the program if it can't.
h
Today it would carry on with a warning, right?
b
Yeah, exactly like that. In a couple places, we have some try/except style imports that I'd like pants to try to infer if it can but be satisfied and carry on with the program if it can't.
How does today's support not suffice?
h
Yes, but I have those elevated to error since it's usually bad coding design
✔️ 1
I found multiple places where folks didn't declare first party dependencies and were gathering things transitively. So I like the default being error for us and explicitly declaring where it's expected.
Otherwise, you have to train developers on which warnings are okay and then you're just crying wolf
b
Right, Pants already treats imports inside a try/except block as "dont complain about it if it can't be inferred". Is that not sufficient?
h
Oh, I hadn't noticed that. I'll double check that's what's happening!
b
🙌
h
Okay, I know why this wasn't happening for us and I'd appreciate some guidance
👀 1
I have modules 
a.py
, 
b.py
, and 
c.py
. The relationship is such that 
a.py
depends on 
b.py
which depends on 
c.py
. In 
a.py
, I have a statement like
Copy code
try:
   import b
except (ImportError, ModuleNotFoundError):
   # Totally okay to happen
   pass
b.py
has a statement like
Copy code
import c
and I was expecting pants to transitively carry through the 
try/except
allowance. 
c.py
missing is actually the thing that causes 
b.py
import to fail. Is our only recourse here to similarly wrap 
import c
in 
try/except
?
b
The dependency parser only tracks/handles direct dependencies
h
Okay, seems easy enough to do a
Copy code
try:
  import c
except ModuleNotFoundError as e:
  raise e
so that it propagates up for the handling we actually wanted
b
I think 
ImportError
is the key, let me check
h
Why not 
ModuleNotFoundError
?
b
🤷‍♂️ FWIW thats a subclass of 
ImportError
So might be "safer" to use 
ImportError
?
h
Yeah, I think wrapping 
import c
is in some sense more “correct” in terms of modeling what’s going on?
h
Yup. We will proceed with that.
3 Views
Open in Slack
PreviousNext
Powered by