https://pantsbuild.org/ logo
Join Slack
Powered by
Found this on 2.9.0rc6: ```❯ ./pants dependencies ...
# general
f
Found this on 2.9.0rc6:
Copy code
❯ ./pants dependencies --transitive aiven/pheme
11:44:23.36 [ERROR] 1 Exception encountered:

  BinaryNotFoundError: Was not able to locate a Python interpreter to execute rule code.
Please ensure that Python is available in one of the locations identified by `[python-bootstrap] search_path`, which currently expands to:
  ['/usr/bin/python3.9']
This can be fixed by changing the path to 
/usr/bin/python
which is a symlink to 
/usr/bin/python3.9
. Seems like the interpreter search is picky about how the file is named maybe? Is this expected?
w
i believe that that means that the interpreter_search path is currently configured on your system to only match 
['/usr/bin/python3.9']
?
you can also adjust the legal names to bootstrap with with https://www.pantsbuild.org/v2.9/docs/reference-python-bootstrap#section-names
f
ahhh... so I should be using something like this if I want to force system python3.9:
Copy code
[python-bootstrap]
search_path = ["/usr/bin"]
names = ["python3.9"]
w
Yea, sorry. We should include those by default I think.
f
I think you do include them (not specifically 
python3.9
)... I'm trying to prevent it from grabbing other installed Pythons (if any)
w
to be clear: the “bootstrap” python is not the python used for your code
f
yes it's the one used to run pants
w
it is only used to run 
@rule
helpers written in Python
right
ok
f
I just want to make it really uniform how we run pants across the org, because I don't want to field a bunch of tickets from people who may have odd python setups
👍 1
w
in that case, requiring 
pyenv
or something is a pretty safe bet
but yea, sounds good.
f
we don't really use pyenv, we use system python almost exclusively
👍 1
is there an env var that tells pants "use this python exactly"?
w
um, semi-magically, i think that https://www.pantsbuild.org/v2.9/docs/reference-python-bootstrap#section-search-path actually supports an explicit binary entry rather than a PATH entry, although it is apparently not documented
oh, hah. which you commented on
f
okay... you have to add the executable to 
names
still, that's what's confusing there
w
a github issue would be welcome there… i’m sure that there is something that needs fixing, not to mention that it’s not documented yet
👍 1
👍🏻 1
f
Copy code
[python-bootstrap]
search_path = ["/usr/bin/python3.9"]
names = ["python3.9"]
this works, but without 
names
it complains with the error I posted in the original thread
👍 1
so I could actually move this to my bootstrap script with...
Copy code
PANTS_PYTHON_BIN=${PANTS_PYTHON_BIN:-/usr/bin/python3.9}
export PANTS_BOOTSTRAP_SEARCH_PATH=$PANTS_PYTHON_BIN
export PANTS_BOOTSTRAP_NAMES=$(basename $PANTS_PYTHON_BIN)
💯 1
also, i'm curious... how the hell does it run a 
@rule
to find the python it needs to run 
@rule
s? What kinda ghost python are you using here? 👻
w
also, i’m curious... how the hell does it run a 
@rule
 to find the python it needs to run 
@rule
 s?
heh. there are entirely too many levels of discovery here. this is for discovering which Python to subprocess python scripts that run in Process sandboxes
🙈 1
it’s also used to run PEX inside sandboxes, which is what mostly then selects interpreters.
https://github.com/pantsbuild/pants/issues/7369 will eventually remove one level of discovery
f
oh yeah, i voted for that issue
4 Views
Open in Slack
PreviousNext
Powered by