zpp.in's shebang line too long in spack build

[etiennemlb]

When building using spack, a python installation that zpp depends on may be located in a deeply nested directory. This is exacerbated by the run path handling of spack (config:install_tree:padded_length), and the fact that on some super computer, the user directories may be nested under more than just /home/. For instance, on Adastra, we have: /lus/home/CT<n>/<proj_id>/<user>.

Any way, we can easily end up with path like this:

/lus/work/BCINES/dci/malaboeuf/spack-user-environments/Binaries/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__s/linux-rhel8-zen3/gcc-13.2.0/python-3.11.9-55eg67r7k27ui2xyv7gcoimkvgmvpkpc/bin/python

Long paths endup in zpp through https://github.com/jbigot/zpp/blob/master/bin/zpp.in:

#!@Python_EXECUTABLE@ -B

And that is an issue because the shebang length is limited to 127 chars (this can be changed by rebuilding the kernel AFAIK). Spack is aware of the issue and uses a workaround, see: https://github.com/spack/spack/blob/develop/bin/sbang

Wouldn't it be better to replace Python_EXECUTABLE by something like #!/usr/bin/env python -B, spack will correctly provide python in the path anyway.

[jbigot]

This is to support in-place usage through CMake. This is never installed, the installed version uses python standard mechanism.

In CMake, one might want to use a non-default python version, for example pointing FindPython to a version in a venv. We should be consistent with that and not use the default python in the current path (also there's no standard specifying that env should be in /usr/bin, but that's just a side remark).

Maybe we could create a shell script that calls python and point to this script in the shebang.

However, if the path to the build directory is too long, we'll end up in the same situation. I don't see any perfect fix.