Someone on my team is having issues running `pants...
# general
d
Someone on my team is having issues running
pants lint ::
on our repo. No one else on the team is able to reproduce the issue. Based on the error, it looks like Pants is trying to use Python 3.7 while building the PEX for black. However: • We have a separate resolve set up for black. It's configured to use Python 3.10.12 • Running
python --version
produces 3.10.12 • Running
pyenv versions
shows both 3.10.12 (required for everything that isn't pants in the repo) and 3.9.5 (required for pants) are installed. • Python 3.10.12 is set via
pyenv global 3.10.12
Why is it trying to use the system Python 3.7? (He's on Mac OSX with an ARM processor like most others on the team) If necessary, I can put together a stacktrace to post (I'll just need some time to obfuscate a couple things)
w
Is this person using
scie-pants
?
And can you share your pants.toml?
d
They installed pants via brew
w
Also, what OS is the mac on? I didn't realize they still came with python3.7
d
I'll ask
Does installing pants via brew use
scie-pants
?
w
Yes
d
So is it likely that when installing Pants, it linked to Python 3.7 instead of 3.9?
He uninstalled pants, cleared the pants cache, and then reinstalled pants, but that hasn't made a difference
w
Pants comes with its own runner, so it should be independent of the system. Ive had this happen a few times in the past, and have seen it in the slack chat - where on some machines, sometimes, the system python on Mac is picked up - either due to a path issue, or something else. I'm away for the next few hours, but maybe this thread might help? I recall there were several issues identified here, maybe one applies? https://pantsbuild.slack.com/archives/C046T6T9U/p1692869602927969
You could also try something like
pants --keep-sandboxes=always lint ::
(or whatever) and then check out the logs for that run in .pantsd and see what python is being picked up in the sandboxes, and that might provide an indication of why it's being picked up. For example, on my machine, there is a sandbox that has this:
Find interpreter for constraints: CPython==3.9.*
And in there, is the __run.sh file that gets called, as well as the path (and whatever else).
d
Thanks for all of the tips. Ultimately, uninstalling Python 3.7.9 from the system / removing it with pyenv fixed the issue