[Feature]: Discussion: How should we make the scripts to run python-only integration test script drivers available through CLI

Description

For this example I will use drunc to describe the workflow, as there are already established integration tests available.

Generally, we will want to be able to run integration test scripts as e.g.

drunc_integtest_bundle.sh

For Spack-deployed repositories, using daqsystemtest as an example, we have the following contents in the $PATH environment variable

printenv PATH | tr ":" "\n" | grep daqsystemtest
/cvmfs/dunedaq-development.opensciencegrid.org/nightly/NFD_DEV_260728_A9/spack-0.22.0/opt/spack/linux-almalinux9-x86_64/gcc-14.3.0/daqsystemtest-NFD_DEV_260728_A9-kv4363vbd354ams7ykhehizrqy32ab4v/bin

which contains the following executables

ls /cvmfs/dunedaq-development.opensciencegrid.org/nightly/NFD_DEV_260728_A9/spack-0.22.0/opt/spack/linux-almalinux9-x86_64/gcc-14.3.0/daqsystemtest-NFD_DEV_260728_A9-kv4363vbd354ams7ykhehizrqy32ab4v/bin
check_example_configs.sh  daqsystemtest_integtest_bundle.sh  dst_get_pytest_tmpdir  dunedaq_integtest_bundle.sh  list_available_integtests.sh  list_repos_with_integtests.sh

This deployment model has not currently been established for the python-only repository structure. A plan needs to be formed for how to make the script executable without a local instance of this.

Potential impact radius

Small/Isolated

Reason for change

Currently to run drunc_integtest_bundle.sh, one has to have a local copy installed, but we want to make this executable if the repository is distributed through CVMFS.

Suggested implementations

The optimal solution would be have a strategy for including the scripts/ path of these repositories as a direct parallel to that of the Spack distributed repositories. This is something I am not currently familiar with, and would like to continue with.

A different solution would be to define the entry point for operating these scripts as a repository entry point, e.g. adding the following to the pyproject.toml

[project.scripts]
<repo_name>_integtest_bundle = '<repo_name>.apps.<repo_name>_integ_tests:main'

and having this script execute the shell script defined in <repo_name>/scripts/<repo_name>_integtest_bundle.sh. An extension to this could be to have the command implemented directly in the script. I have a preference for hadnling the entry points to the integration test bundle driver scripts the same as for Spack-deployed repositories to minimise differences between the repository structures.

Testing suggestions

Generate a nightly environment once the changes have been implemented, and check whether the entry point is available without having a local copy of the relevant repository.

Anything else?

N/A.

Start by reviewing the repository's scripts/ layout and pyproject.toml, then compare the existing drunc_integtest_bundle.sh and Spack-installed entry points. Determine which packaging approach fits the Python-only repositories and verify it in a generated nightly CVMFS environment. Done means the integration-test bundle command is available without a local repository copy.