Do Pants plugin tests assume a specific python version on run? I just got hit with

E           Engine traceback:
E             in select
E             in experimental.pyoxidizer.rules.package_pyoxidizer_binary (src:test-bin)
E             in pants.backend.python.util_rules.pex.create_pex (pyoxidizer.pex)
E             in pants.backend.python.util_rules.pex.build_pex (pyoxidizer.pex)
E             in pants.backend.python.util_rules.pex.find_interpreter (CPython>=3.8)
E             in pants.engine.process.fallible_to_exec_result_or_raise
E             in pants.backend.python.util_rules.pex_cli.setup_pex_cli_process
E             in pants.backend.python.util_rules.pex_environment.find_pex_python
E             in pants.python._binaries_rules.find_python
E           Traceback (most recent call last):
E             File "/Users/sj/.cache/pants/named_caches/pex_root/venvs/de04010553f1713b72512ad07d1b20b66bf8f840/f5cef8ebdbaf03ed774d467ae52a457e8fe3774a/lib/python3.9/site-packages/pants/engine/internals/selectors.py", line 705, in native_engine_generator_send
E               res = func.send(arg)
E             File "/Users/sj/.cache/pants/named_caches/pex_root/venvs/de04010553f1713b72512ad07d1b20b66bf8f840/f5cef8ebdbaf03ed774d467ae52a457e8fe3774a/lib/python3.9/site-packages/pants/python/_binaries_rules.py", line 82, in find_python
E               raise BinaryNotFoundError(
E           pants.engine.process.BinaryNotFoundError: Was not able to locate a Python interpreter to execute rule code.
E           Please ensure that Python is available in one of the locations identified by `[python-bootstrap] search_path`, which currently expands to:
E             []

Does "it" in that sentence mean the Pants process that is running your tests?

"it" in that case is that which caused the error, which is the

./pants test ::

command

There are two different interpreters in play: 1) The one Pants itself runs on when you run

./pants test ::

, 2) The one that the pex-creation rule invokes

This does beg the question about whether I should be using the ./pants test :: command or not - I'm assuming so, but 🤷

Yes,

./pants test

is the right way to run your tests, even if they are testing a plugin

THere we go, that did it!

Everything is very hermetic and locked down by default

So, I was structuring my code around what's in the repo - but I guess that has runners setup to avoid all these problems

the pants.toml for Pants itself has:

[test]
extra_env_vars = [
  # TODO: These are exposed to tests in order to allow for python interpreter discovery when
  # Pants-tests-Pants: in particular, the [python] subsystem consumes them.
  #   see <https://github.com/pantsbuild/pants/issues/11638>
  "PYENV_ROOT",
  "HOME",
  "PATH",
  # We'd always like complete backtraces in tests.
  "RUST_BACKTRACE=1",
]

Ah, okay, that's interesting - I'd never thought of them wrt python tests, as I'd never had issues with tests until writing this first plugin

So your previous tests probably didn’t invoke any Python interpreter from the test code, then.. 🙂

Seems that way - interestingly, I pulled down the pants repo in prep of doing a pull request for my plugin, and for the sake of it, ran ./pants test :: and a whole ton of those tests failed too. So, I'm not really sure what's going on. Very strange stuff. The experience of writing a plugin has been pretty seamless once I get that baseline knowledge I need, but it turns out that writing tests has ended up being more difficult 😅

yeah, tests can be a bit intimidating to get the hang of.. esp rule graph issues 😅

The rule graph was surprisingly the simplest - I still haven't gotten a successful "approach 3" or "approach 4" to work for the tests. What I'm doing right now is forking and merging my code, and I'll try running tests in the main pants repo - as I think that's a more reliable approach at the moment

Hmm

./pants test ::

failed on your laptop? That's not ideal

Okay, so still not luck passing any RoleRunner or run_pants tests. As a sanity test, why would this give me a ModuleNotFoundError for "pants.backend.experimental.python.packaging.pyoxidizer"?

pants_run = run_pants([
    "--backend-packages=['pants.backend.python', 'pants.backend.experimental.python.packaging.pyoxidizer']",
    "help",
    "pyoxidizer_binary"])
pants_run.assert_success()

For this, I'm running

./pants test src/..../pyoxidizer:rules_integration_test

Oh yeah, MacOS pythons are broken in all sorts of weird ways

Yeah, looks like it was never using my Brew installed python in the first place, so that's one problem. I just wiped the .pids and .pants.d and set PY=python3.9, and it's now modifying the Rust build - which is nice. I'll report back if there are any test suite failures still. However, none of this affects my sanity test I don't think - can't seem to find the experimental package registration.

Is it running Pants itself on 3.8, or running your tests on 3.8?

This whole thing is blowing my mind right now. I don't know by which mechanism this Xcode python3 was even discovered - even after I manually sourced the pants_venv file. I pulled pants main branch today, so I should be inline with that, other than my PR. In there, we have

[python]
experimental_lockfile = "3rdparty/python/lockfiles/user_reqs.txt"
interpreter_constraints = [">=3.7,<3.10"]
macos_big_sur_compatibility = true

This is for going to the root folder and typing

./pants test ::

So PY= affects the interpreter Pants runs itself on, not the interpreter it selects to run your code on

Yeah, that's what it looks like when I dig in the logs - the very first thing that it asks for is the "correct" constraints and grabs my 3.9, but then I see it looking for other constraints later. However, I forced the constraints to be >=3.9, and its looking better

According to the docs, it looks in my path, and pyenv. I don't have pyenv installed, and using any Python3.8 command, I can't find that Python on my path.