https://pantsbuild.org/ logo
Join Slack
Powered by
I have a weird one... `pylint path/to/somewhere` w...
# general
p
I have a weird one... 
pylint path/to/somewhere
works... 
pants lint --only=pylint path/to/somewhere ::
fails. In particular, this is about generated protobuf files *_pb2.py[i]. I know the config file is being picked up as if I modify the summary.. it no longer shows the summary when run with pants. 🤔 I do have pants ignoring the generated proto files too.
g
Are you running the verbatim commands? The space between 
path/to/somewhere
and 
::
means they're two separate targets.
p
Oh sorry I don't actually have the path/to/somewhere
1. pylint . 2. pants lint --only=pylint ::
1 works 2 fails
g
Gotcha, thanks for clarifying! When you say "fails", do you mean that pylint exits with an error or that pants gives you an error? Are you able to share any logs?
p
Stuff like this
Copy code
E0611: No name 'StationInformation' in module 'blah.messages.v1.observation_pb2' (no-name-in-module)
Actually all are no-name-in-module for the generated _pb2* proto files
g
Does your regular code find them correctly, and it's only pylint that fails?
p
Yes
pylint + pylintrc works pants + pylint + pylintrc doesnt 😕
g
I re-activated pylint in my work repo and tried to reproduce, and I'm seeing the same thing. We used to use 
protobuf-pylint
but that doesn't work with protoc 3.20, so it seems like 
pyi
files is the goto. But pylint does not seem to pick them up, and doesn't support picking them up as I understand it. So... are you using the same protoc as with Pants, and the same pylint in/out?
p
Hmm how do I check what pants is using?
g
If you've not set something in 
pants.toml
(
[protoc].version
) it'd be 3.20.1 for stable Pants.
p
Indeed... 
3.19.4
is what we are running.
Let me switch on pants side.
g
That should probably work with 
pylint-protobuf
plugin, if so.
OK; so. I downgraded to 3.11.4 (from Pants 2.11, which I could find SHAs for). With
Copy code
[pylint]
extra_requirements = [pylint-protobuf]
lockfile = "locks/pylint.lock"

[protoc]
version = "3.11.4"
known_versions = [
  "3.11.4|linux_arm64 |f24c9fa1fc4a7770b8a5da66e515cb8a638d086ad2afa633abb97137c5f029a8|1481946",
  "3.11.4|linux_x86_64|6d0f18cd84b918c7b3edd0203e75569e0c8caecb1367bbbe409b45e28514f5be|1591191",
  "3.11.4|macos_arm64 |8c6af11e1058efe953830ecb38324c0e0fd2fb67df3891896d138c535932e7db|2482119",
  "3.11.4|macos_x86_64|8c6af11e1058efe953830ecb38324c0e0fd2fb67df3891896d138c535932e7db|2482119"
]
And
Copy code
[MASTER]
load-plugins=pylint_protobuf
I get a passing pylint.
I'm not sure about 3.19.4 but it should work with the plugin, as 3.20 was the breaking change to descriptors. So I'm wondering whether you're not getting the plugin loaded properly at all, and pylint just trucks on without it.
p
I can try after my next meeting.
Sorry about that... day got away from me. Downgrading to 3.11.4 works for me.. not sure of the differences between the two 3.11/3.19 as of yet. 🤔
Okay locking to 3.19.4 and ignoring 
protobuf-undefined-attribute
seems to do the trick
Open in Slack
PreviousNext
Powered by