Hi, I am having trouble with running a django app, or any other app via pants, due to the python interpreter not being found:

08:58:07.37 [ERROR] 1 Exception encountered:

Engine traceback:
  in `run` goal - environment:local

ProcessExecutionFailure: Process 'Find interpreter for constraints: CPython==3.8.*' failed with exit code 1.
stdout:

stderr:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/local/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/tmp/pants-sandbox-YzENq0/.tmp/tmp26el07zn/__main__.py", line 106, in <module>
    bootstrap_pex(__entry_point__, execute=__execute__, venv_dir=__venv_dir__)
  File "/tmp/pants-sandbox-YzENq0/.tmp/tmp26el07zn/.bootstrap/pex/pex_bootstrapper.py", line 615, in bootstrap_pex
    maybe_reexec_pex(interpreter_test=interpreter_test)
  File "/tmp/pants-sandbox-YzENq0/.tmp/tmp26el07zn/.bootstrap/pex/pex_bootstrapper.py", line 390, in maybe_reexec_pex
    resolved = target.resolve_base_interpreter()
  File "/tmp/pants-sandbox-YzENq0/.tmp/tmp26el07zn/.bootstrap/pex/interpreter.py", line 1182, in resolve_base_interpreter
    raise self.BaseInterpreterResolutionError("\n".join(message))
pex.interpreter.BaseInterpreterResolutionError: Failed to resolve the base interpreter for the virtual environment at /company/dist/export/python/virtualenvs/default/3.8.17.
Search of base_prefix /usr/local found no equivalent interpreter for /company/dist/export/python/virtualenvs/default/3.8.17/bin/python3.8



Use `--keep-sandboxes=on_failure` to preserve the process chroot for inspection.

The python interpreter does exist in my dist folder under:

dist/export/python/virtualenvs/default/3.8.17/bin/python

Has anyone had similar problems before?

Pants looks for interpreters where you tell it to look, using https://www.pantsbuild.org/docs/reference-python-bootstrap#search_path

Thank you for your answer! I added this to my pants.toml file:

[python-bootstrap]
search_path = ["/usr/local/bin/python"]

Afterwards I reinstalled pants and I no longer have this issue

@happy-kitchen-89482 why is it necessary to include a bootstrap search path since we're using scie-pants which should download and cache a standalone python interpreter by itself. adding this search path would cause pants to use a different interpreter already installed on the system or? https://www.pantsbuild.org/docs/installation#the-pants-binarys-implementation

python-bootstrap

controls where Pants looks for interpreters to be used with your code (e.g., to run your tests). The standalone python interpreter is purely an implementation detail that should not be used for your code.

Thanks!

@happy-kitchen-89482 We are facing this issue again on 2.16 and after I have updated to Python 3.11. This only occurs when pants is invoked from a Python subprocess like this:

process = subprocess.Popen(
            ["pants", "run", "django/manage.py", "--", "migrate"],  # noqa: S603
            stdout=subprocess.PIPE,
            stderr=subprocess.STDOUT,
        )

Invoking the command directly works. If I add back this it also works when invoked from the subprocess:

[python-bootstrap]
search_path = ["/usr/local/bin/python"]

Any idea why?

Try running

pants help python-bootstrap

in the subprocess and directly, and see if

search_path

has different values in each case

Okay, it is for both:

current value: [
          "<PYENV>",
          "<PATH>"
      ]

PYENV is not set for any of the two. For PATH both have

/usr/local/bin

. I am a bit confused

What happens if you turn off all caching (

--no-local-cache

,

--no-pantsd

) ?

@happy-kitchen-89482 No, that does not help. But I think I figured out what the problem is: When adding

print(env["PATH"])

before the subprocess call, I can see that the first entry is something I am not seeing in my normal bash:

/tmp/pantsbuild/pants-sandbox-5NyfTp/.cache/pex_root/venvs/4eb70be5ead3e38b8fe83ba6d941fbd121ff672b/3bd8dd039b6717ea08ba315fc4068d8debf47674/bin:/home/vscode/.local/bin:/home/vscode/.pulumi/bin:/usr/local/python/current/bin:/usr/local/py-utils/bin:/usr/local/share/nvm/current/bin:/usr/local/bin:/usr/local/share/nvm/versions/node/v16.20.2/bin:/vscode/vscode-server/bin/linux-x64/8b617bd08fd9e3fc94d14adb8d358b56e3f72314/bin/remote-cli:/usr/local/sbin:/usr/sbin:/usr/bin:/sbin:/bin:

I think I did not mention one small detail: That python file where pants is called in turn is called by pants with

pants run

. So I guess pants is adding that sandbox here and there it is looking for an interpreter there, which is of course not present. This also happens when I call a packaged PEX for this programm as well. What confuses me is that this seems not related to the pants version as that did not change but due to the Python version?!

So to clarify, you're using Pants to execute a python script that itself uses

subprocess

to execute

pants run

, so Pants within Pants?