<@U04S45AHA> I’ve stumbled across an old TODO with...
# development
s
@enough-analyst-54434 I’ve stumbled across an old TODO with your name on it - wondering if I can wipe it out 🧵
it looks like the linked issue was fixed in astroid 2.9.1
but I’m not sure how far back in the pylint version history we want to support - any thoughts?
b
In other rules, we change behavior based on tool version. Can you do that here?
s
🧠
is it possible to get the version of an arbitrary third-party dependency (vs. the top-level tool where we have a dedicated config for the version)? so we could check against astroid directly?
e
Not really without importing it.
b
Anything is possible 😛 The question is how much pain you wanna feel
hurtrealbad 1
e
You'd need a process that used importlib
b
Presumably the middle-ground is looking for pylint version that contains asteroid version with the fix. If people are bumping asteroid later in an earlier Pylint they'll just get a slower run than if not?
Yeah, you could also dig into PEX metadata. 18 ways here.
s
if we took the middle ground, looks like pylint 2.13.0 is the cutoff
b
FWIW
importlib.metadata
is Python 3.8, but Pants currently runs on 3.7. Thats why I can't use it directly in
debugadapter
code. You have to ask for a PEX containing the backport 😭
Yeah, you could also dog into PEX metadata. 18 ways here.
Thatd be my suggestion of the "right" way
I'd honestly +1 either solution. Try the "correct" way by asking/inspecting PEX and if that gets too hard, do the middle-ground with a comment?
s
https://github.com/pantsbuild/pants/pull/17488 I think I figured out how to make it work the “right” way 🤔