[DRAFT] PyTrilinos2: Switch to "primary tested"

[cgcgcg]

@trilinos/pytrilinos2

Motivation

Switch PyTrilinos2 to "primary tested" so that the AT builds it.

This will fail with AT1 since binder is not available, but AT2 should pass.

[cgcgcg]

@sebrowne @jmlapre The AT2 builds are picking up the wrong Python, see e.g. here:
https://sems-cdash-son.sandia.gov/cdash/build/343996/configure
CMake finds Python 3.8

-- Found Python3: /home/Trilinos/build/bin/python (found suitable version "3.8.17", minimum required is "3.6") found components: Interpreter

but later on a PyBind11 is used that was installed for Python 3.11

-- pybind11 CMake path: /home/runner/spack/opt/spack/linux-rhel8-x86_64/gcc-10.3.0/py-pybind11-2.11.1-jewrkhs52qqx4paehddpqxje3rzydb74/lib/python3.11/site-packages/pybind11/share/cmake/pybind11

Should the variable here

Trilinos/packages/framework/ini-files/environment-specs.ini

Line 175 in 44c598a

envvar-find-in-path PYTHON_EXECUTABLE : python3

be Python3_EXECUTABLE (see #13523) ?

[sebrowne]

Should the variable here

Trilinos/packages/framework/ini-files/environment-specs.ini

Line 175 in 44c598a

envvar-find-in-path PYTHON_EXECUTABLE : python3

be Python3_EXECUTABLE (see #13523) ?

Yes I believe that will work. I'm not positive that the python3 installed by Spack is in PATH prior to the system one, but if it is, then that should change it such that TriBITS picks up the Spack-installed one (which is the one we want given that it's the one used for the Python packages). If it's not (my guess), then you can test out adding a module load python right before calling the PullRequestLinuxDriverTest.py in AT2.yml (and long term we can add that module load to the container config so it's automatic). An alternative approach would be to detect the Python installed with the system via an external, but that may be a heavier lift and would require rebuilding the containers. Then there's only one version of Python, and nothing to get cross-wired.

EDIT: I just checked, and yes /usr/bin/python3 is in PATH by default, and yes module load python fixes that (we didn't explicitly load python, but we did load pybind11, etc.). I will add a module load python to the container recipes and that should take effect tonight. Until then, you can work around it via a module load python in the AT2.yml file.

[cgcgcg]

Perfect, thank you @sebrowne ! I'm more than happy to wait until tomorrow ;-)

[sebrowne]

Perfect, thank you @sebrowne ! I'm more than happy to wait until tomorrow ;-)

It may be Thursday, there's a multiple-nightly-process coordination thing going on. Tonight our process will deploy our container, then the AT2 team will grab that and layer on top of it tomorrow evening. If all goes quickly, it CAN happen in one night.

[cgcgcg]

No worries. This change won't merge until we are fully switched over to AT2 anyway.