https://pantsbuild.org/ logo
Join Slack
Powered by
Q. Is there a way to programmatically retrieve the...
# general
r
Q. Is there a way to programmatically retrieve the Python interpreter that Pants is using? (version, path, etc.)
e
That Pants itself is running under? That would be 
sys.version_info
, 
sys.executable
, etc. This is the same as for any other Python program. What context do you want to use this information in?
r
i'd like to write a script that automatically invokes a shell command inside the exported venv
in my case, the venv's path is 
dist/export/python/virtualenvs/python-default/3.10.4/
i'd like to fill the 
3.10.4
piece automatically
e
Ah - that's not the Python interpreter Pants is running under then, its the one it picked to satisfy your own code's 
interpreter_constraints
.
The only way to retrieve that is by writing a plugin. In other words, in rule code.
r
hmm ok
e
Is there a reason you can't just glob? Do you expect multiple Python versions per each exported resolve venv?
r
i also want to write a script that bootstraps Pants either running 
./pants version
or source-building the github clone after 
./pants version
fails (e.g., linux-aarch64)
i just want to eliminate any possibility to have multiple versions there
because in my team, we frequently update the python versions
(e.g., i have contributed some patches to CPython 3.10.0 and 3.10.1 which affected my team's codebase)
e
Do you update frequently with tight control? In other words - if you know your repo must be using 
interpreter_constraints = ["==3.10.1"]
then you can get the value from 
pants.toml
.
Or do you update frequently but let things run loose? 
interpreter_constraints = ["==3.10.*"]
?
r
the latter
hmmm
e
So some people use 3.10.0 and some use your 3.10.1 patched CPython?
r
it might be better to specify the exact version in pants.toml
as you mentioned
e
Yeah, sounds like it.
r
we tend to stick with the latest python versions
then now the problem is converted to reading toml in a shell script 😉
e
Do you have any regular env var setup for devs?
There is now 
%(env.VAR_NAME)s
that can be interpolated in pants.toml.
So if you know the exact python version, export it in an env var, both the pants.toml and your shell script can read that env var.
r
no, we don't put any particular env-vars by default but have wrapper scripts that configures them for specific execution of commands
i think i could just use regex pattern matching
e
Do you run 
./pants
or use a wrapper script to run pants?
r
since one of the major target platform is linux-aarch64, in that platform, we need to use a custom-patched source build of pants
in other case, we will use just 
./pants
e
Ok.
r
but in our automated dev-setup script, i'd like to do this process automatically
and that script also checks the available Python versions in the system and installs one using pyenv
and i'd like to keep the python interpreter used by pants, the python interpreter inferred by the constraint configs by pants, and the python interpreter installed via pyenv all consistent
one issue here is that pants had some issues on Python 3.10 when itself runs on it while using Python 3.10 as the constraint was fine
so i'd like to detect & auto-install both Python 3.9 (for pants itself) and 3.10 (for our codebase handled by pants)
c
OK, this may not be exactly what you’re looking for, but felt like sharing as at least related, to your original question. We have a project where we use 
python-behave
for writing a set of tests in Gherkin (cucumber), and to get going quickly we didn’t start off with writing a Pants plugin to support running it natively with 
./pants test
but instead ended up with this 
Makefile
to get going:
Copy code
$ cat Makefile 
VENV_ROOT ?= dist/export/python/virtualenvs/python-default
BEHAVE ?= $(shell find -x $(VENV_ROOT) -name behave -type f)

# Testrun event data
BACKEND ?= 
BUILD_URL ?= local
JOB ?= sputnik.api.cucumber.python
PROJECT_NAME ?= tooling/systemtest
TENANT ?= common
TEST_TYPE ?= api
TPNS ?= test1

check: venv
	$(BEHAVE) \
		-D backend=$(BACKEND) \
		-D build_url=$(BUILD_URL) \
		-D job=$(JOB) \
		-D project_name=$(PROJECT_NAME) \
		-D tenant=$(TENANT) \
		-D test_type=$(TEST_TYPE) \
		-D tpns=$(TPNS) \
		src/features

%.lock: %.txt
	./pants generate-lockfiles

venv: $(VENV_ROOT)

$(VENV_ROOT): deps/requirements.lock
	./pants export ::
So a simple 
make check
is all that you need to know from a clean 
git clone
🙂
👀 1
5 Views
Open in Slack
PreviousNext
Powered by