https://pantsbuild.org/ logo
Join Slack
Powered by
I've finally found that why many open source contr...
# general
r
I've finally found that why many open source contributors to Backend.AI has suffered from the pants installation: https://github.com/lablup/backend.ai/issues/690 If we could have macOS + arm64 wheel for Python 3.8.9 (the system Python shipped with macOS Monterey), the life would become much easier. 😉
w
In reading that ticket, for M1 Macs, wouldn't the problem of not having 3.9 installed still be present? As per: https://www.pantsbuild.org/docs/prerequisites#macos What happens when you just install python3.9 from brew, instead of installing the unconstrained 
python3
? 
brew install python@3.9
- does Pants not pick that up correctly? This isn't scalable, but if you need to specify the location to a Python install, could you use the 
.pants.rc
file? https://www.pantsbuild.org/docs/options#pantsrc-file Also, just a heads up that you might like this (very much still in development, but should be awesome when done): https://github.com/pantsbuild/pants/pull/16484
👀 1
r
Experienced contributors just know what to do by "self-debugging" their envs and the docs. The problem is when we are going to guide/teach novice open source contributors. We have suffered from an endless stream of questions about difference of Pants-required Python (3.9.x) and our project-required Python (3.10.5) and why we should install two Python versions, etc. Also, unfortunately in this case, most existing devs did not have the issue but only newcomers with fresh install of homebrew Python had issues -- this led to "the problem is not reproduced in my machine".
If we have Python 3.8 wheel for macOS arm64, most of such novice contributors would not face the missing wheel and Python environment problem at all in the first place.
(Fixing our repo as described in the linked issue will also help them, but still we need to describe why you have to install two Python versions.)
This is not a very technical issue but rather a usability "at a first glance" issue. I'm just sharing my experience, with a check for the possibility to have Python 3.8 wheels for the macOS arm64 platform to ease the situation, but without strong opinion.
❤️ 1
As you noted, it would be nice if we could have a standalone fully self-contained executable of Pants (which already includes a statically built Python runtime as well) in its supported platforms.
You might be interested at this repository with statically built Python binaries for various target platforms.
.pants.rc
is not what I want because my project is already using Python 3.10, which is different from the supported versions (3.7, 3.8, 3.9) of Pants 2.13. I just want to override the Python interpreter path only for the 
./pants
script and Pants itself, not for my project codes, depending on how Python 3.9 is installed and discovered in the developer's machines.
w
https://github.com/indygreg/python-build-standalone/releases
We're using PyOxidizer which is created by Greg - it was the first plugin I added to Pants 🙂
❤️ 1
I just want to override the Python interpreter path only for the 
./pants
script and Pants itself, not for my project codes, depending on how Python 3.9 is installed and discovered in the developer's machines
This is what I do:
Copy code
[python-bootstrap]
search_path = ["/usr/local/bin"]
r
Ahha, that looks like a good alternative to 
.pants.bootstrap
w
Inside the 
.pants.rc
I do agree, overall, that there are some challenges with differing python versions, and just onboarding as a result - especially when Pants requires one Python version, while your code uses a different one
r
Yeah, I love what Pants offers to me overall, but it's a challenge to describe what Pants is and why we need multiple Python versions to be installed, etc. when onboarding relatively less experienced developers.
😭 1
Open in Slack
PreviousNext
Powered by