I'm trying to get our build working on a co-worker...
# general
p
I'm trying to get our build working on a co-workers Mac laptop. We're building with Python3.7:
Copy code
[python-setup]
interpreter_constraints = ['CPython==3.7.*']
but when she runs the
pants
wrapper script she's getting an error that says `ProcessExecutionFailure: Process 'searching for
python2
...` . She does have various
python3
aliases set up via
pyenv
so I'm not sure why it's looking for Python2. In the error you can see that it ran
which -a python2
which fails because there is not
python2
on the
$PATH
. There is a
python2.7
which I could symlink but I'm wondering why it's looking for Python2 at all.
h
hm what's the failure say?
what's happening is that we use Pex to do interpreter discovery. But before that happens, we need to find a Python interpreter to run Pex itself: https://www.pantsbuild.org/docs/reference-pex#section-bootstrap-interpreter-names Pex works w/ Py27 and Py3, hence we consider if
python2
is there. But we shouldn't be failing. You can try changing that option, although definitely interested in the error
p
Here's the screen shot my colleague sent me:
h
do they have access to the bottom of that, the rest of stderr?
p
I can get it. I have a meeting with her a 2:30pm Pacific time today to try to get things working and get can that for you then.
👍 1
h
Also, is this Pants v1?
h
2.4.0 according to stacktrace
p
yup, 2.4. Waiting on a bug fix to upgrade to 2.5.
Actually, just checked issues - looks like my bug was fixed and we can upgrade.
🙌 1
@hundreds-father-404 here's the full output:
Copy code
15:23:51.60 [INFO] initializing scheduler...
15:23:52.68 [INFO] scheduler initialized.
15:23:53.07 [ERROR] Exception caught: (pants.engine.internals.scheduler.ExecutionError)
  File "/Users/ckolson/.cache/pants/setup/bootstrap-Darwin-x86_64/2.4.0_py38/lib/python3.8/site-packages/pants/bin/local_pants_runner.py", line 229, in _run_inner
    return self._perform_run(goals)
  File "/Users/ckolson/.cache/pants/setup/bootstrap-Darwin-x86_64/2.4.0_py38/lib/python3.8/site-packages/pants/bin/local_pants_runner.py", line 168, in _perform_run
    return self._perform_run_body(goals, poll=False)
  File "/Users/ckolson/.cache/pants/setup/bootstrap-Darwin-x86_64/2.4.0_py38/lib/python3.8/site-packages/pants/bin/local_pants_runner.py", line 185, in _perform_run_body
    return self.graph_session.run_goal_rules(
  File "/Users/ckolson/.cache/pants/setup/bootstrap-Darwin-x86_64/2.4.0_py38/lib/python3.8/site-packages/pants/init/engine_initializer.py", line 135, in run_goal_rules
    exit_code = self.scheduler_session.run_goal_rule(
  File "/Users/ckolson/.cache/pants/setup/bootstrap-Darwin-x86_64/2.4.0_py38/lib/python3.8/site-packages/pants/engine/internals/scheduler.py", line 530, in run_goal_rule
    self._raise_on_error([t for _, t in throws])
  File "/Users/ckolson/.cache/pants/setup/bootstrap-Darwin-x86_64/2.4.0_py38/lib/python3.8/site-packages/pants/engine/internals/scheduler.py", line 498, in _raise_on_error
    raise ExecutionError(
Exception message: 1 Exception encountered:
  ProcessExecutionFailure: Process 'Searching for `python2` on PATH=/Users/ckolson/.pyenv/versions/3.7.10/bin:/Users/ckolson/.pyenv/versions/3.8.9/bin:/Users/ckolson/code/env/bin:/Users/ckolson/google-cloud-sdk/bin:/Users/ckolson/.pyenv/shims:/Users/ckolson/.pyenv/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin' failed with exit code 1.
stdout:
stderr:
+ command -v which
+ command which -a python2
+ which -a python2
(Use --print-stacktrace to see more error details.)
h
Hm, what happens when you run
which -a python2
directly?
fyi this is the script being run:
Copy code
set -euox pipefail

        if command -v which > /dev/null; then
            command which -a $1 || true
        else
            command -v $1 || true
        fi
I'm confused why the
|| true
isn't working... To debug, it may help to use `--no-process-execution-local-cleanup`: https://www.pantsbuild.org/v2.4/docs/troubleshooting#debug-tip-inspect-the-chroot-with---no-process-execution-local-cleanup
p
I'm afraid I don't have a Mac and the person who had this issue isn't available to help with this. But the ``bootstrap_interpreter_names` fix worked so we're not blocked anymore.
I'm not super familiar with the semantics of
set -e
but could that be the issue: a command did fail so maybe that takes precedence over the
|| true
?
If you wanted to debug you could probably set
bootstrap_interpreter_names
to something you know doesn't exist like
foo_python
and see it fail.
Thanks a ton for all your help!
❤️ 1
h
Oh....that's it. Thank you, Oliver!! Fixing now and will cherry-pick
👍 1