GH-45716: [R][CI] Refactor skip_on_python_older_than to not initialize reticulate

[amoeba]

Rationale for this change

This fixes our test-r-offline-maximal job which started failing because of a change in reticulate 1.41.0.

What changes are included in this PR?

Changed internals of our skip_on_python_older_than helper.

Are these changes tested?

Locally, need to test in CI before merging.

Are there any user-facing changes?

No.

• GitHub Issue: [R][CI]: failing to activate python venv after installation #45716

[amoeba]

@github-actions crossbow submit test-r-offline-maximal

[github-actions]

Revision: c76756e

Submitted crossbow builds: ursacomputing/crossbow @ actions-d817e71ea4

Task	Status
test-r-offline-maximal

[amoeba]

Crossbow job passes, I see the test we expect to be skipped skips when checking Python version,

2025-04-09T23:48:59.5925641Z Start test: install_pyarrow
2025-04-09T23:48:59.5925766Z   'test-python.R:26:3' [skip] <-- this is `skip_on_python_older_than("3.9")`
2025-04-09T23:48:59.5925883Z End test: install_pyarrow

I'm going to exercise the new helper code by installing a newer Python version in the runner temporarily.

[amoeba]

@github-actions crossbow submit test-r-offline-maximal

[github-actions]

Revision: c82635de9d908644f7476f20c5c752df9c13fdc8

Submitted crossbow builds: ursacomputing/crossbow @ actions-accaa08b45

Task	Status
test-r-offline-maximal

[amoeba]

I had hoped to exercise the new helper code (I still can) but I figured something out that makes me think we can just merge this as-is.

The skip I mentioned above was actually because "Python not available" not because we fail the version check as I had hoped. This happens due to what appears to be a bug in reticulate which is confusing because it's a very basic thing to have not work. The code in this PR uses reticulate::py_discover_config() which claims to tell us what reticulate will find when it goes looking for a Python installation. The documentation claims it follows Order of Discovery which, if you read all the way through, item 15 says it will search the PATH for python or python3.

However, in a VM with R and python3 in the PATH, I get,

> py_discover_config()
NULL

This seems to be a bug and may explain why none of our CI jobs actually run the reticulate tests @jonkeane. If I explicitly tell reticulate which Python to use, this new helper works fine,

> Sys.setenv("RETICULATE_PYTHON"="/usr/bin/python3")
> py_discover_config()
python:         /usr/bin/python3
libpython:      /usr/lib/python3.12/config-3.12-aarch64-linux-gnu/libpython3.12.so
pythonhome:     //usr://usr
version:        3.12.7 (main, Feb  4 2025, 14:46:03) [GCC 14.2.0]
numpy:           [NOT FOUND]

[jonkeane]

This seems to be a bug and may explain why none of our CI jobs actually run the reticulate tests @jonkeane. If I explicitly tell reticulate which Python to use, this new helper works fine,

Do our force all tests checks actually run this? Or are those skipping there too?

[jonkeane]

Thanks for this. Yeah, I definitely agree this is an improvement even if it's not totally what we were hoping for

[amoeba]

Do our force all tests checks actually run this? Or are those skipping there too?

It seems so, in the logs of the AMD64 Ubuntu 24.04 R 4.4 Force-Tests true check:

2025-04-09T23:35:56.4750365Z Start test: install_pyarrow
2025-04-09T23:35:56.4750466Z Using Python: /usr/bin/python3.12
2025-04-09T23:35:56.4750588Z Creating virtual environment 'arrow-test' ..

I'm not sure reticulate picks up /usr/bin/python3.12 there but not in my local testing though. So it's not that we're not running the reticulate checks but there's maybe something special going on in this check.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 409a016.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 1 possible false positive for unstable benchmarks that are known to sometimes produce them.