Q. Is there a way to programmatically retrieve the...
# general
Q. Is there a way to programmatically retrieve the Python interpreter that Pants is using? (version, path, etc.)
That Pants itself is running under? That would be
, etc. This is the same as for any other Python program. What context do you want to use this information in?
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
i'd like to fill the
piece automatically
Ah - that's not the Python interpreter Pants is running under then, its the one it picked to satisfy your own code's
The only way to retrieve that is by writing a plugin. In other words, in rule code.
hmm ok
Is there a reason you can't just glob? Do you expect multiple Python versions per each exported resolve venv?
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)
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
Or do you update frequently but let things run loose?
interpreter_constraints = ["==3.10.*"]
the latter
So some people use 3.10.0 and some use your 3.10.1 patched CPython?
it might be better to specify the exact version in pants.toml
as you mentioned
Yeah, sounds like it.
we tend to stick with the latest python versions
then now the problem is converted to reading toml in a shell script 😉
Do you have any regular env var setup for devs?
There is now
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.
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
Do you run
or use a wrapper script to run pants?
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
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)
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
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
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
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) \

%.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