Repository: spack/spack

Issue:
Automatically use Python 3 if available
As discussed during today's BoF, some people would like Spack to use Python 3 if available. Since we cannot depend on any version of Python being available on all systems, this needs a slightly complex approach: The spack binary is moved to spack-real and replaced by a shell script that checks for available versions of Python (preferring Python 3) and invokes spack-real accordingly.

This should also take care of the situation where no python binary is available (as will be on RHEL 8 by default).

Not sure if this is really the best way to go but I have been meaning to take a stab at this for a while now. (Only tested on Linux.)
@tgamblin @alalazo @becker33 @adamjstewart


Discussion:
Also @citibeth who has worked on related Python3 concerns in Spack (although generally more-related to building Spack packages with Python3 rather than using Python3 to run Spack):

See also:

* https://github.com/spack/spack/issues/11468
* https://github.com/spack/spack/pull/10319
* https://github.com/spack/spack/pull/7926
Adding an extra shellscript in front sounds like a Java nightmare to me.  Why not just use whatever Python the system provides?  In my experience, Spack works fine with either.
I agree with @citibeth, if users really want to test `python3`, they can alias `python` to `python3`.
Another simpler way to do it would be to just rewrite the #/usr/bin/env line at the top of `bin/spack` when you install.  Why don't we just do that?  A simple "switcher" script could be made to do that, similar to the way MacPorts and CentOS allow you to "select" certain versions.  Then the 99% of users who don't need this functionality won't need to deal with the cruft it brings every time the program is run.
 
> Another simpler way to do it would be to just rewrite the #/usr/bin/env line at the top of `bin/spack` when you install. Why don't we just do that? A simple "switcher" script could be made to do that, similar to the way MacPorts and CentOS allow you to "select" certain versions. Then the 99% of users who don't need this functionality won't need to deal with the cruft it brings every time the program is run.

I like that idea (will give it a go once ISC is over). It might still make sense to default to python3 at some point since at least a few Linux distributions are dropping the python binary soon (Fedora, RHEL/CentOS).
>
>
> It might still make sense to default to python3 at some point since at
> least a few Linux distributions are dropping the python binary soon
> (Fedora, RHEL/CentOS).
>
The problem here is, many of us are stuck using HPC Linux systems from the
stone age.  For example, the supercomputer I'm on uses CentO6 (I believe).
It's so old, it can't even do HTTPS to most websites these days.  That's
why Spack is tested to work with Python 2.6.

If future distros are to drop the `python` command, then I really don't
know what I think the best solution to this problem is.  At least we have
two approaches here.

-- Elizabeth


Resolving patch:
diff --git a/lib/spack/spack/cmd/license.py b/lib/spack/spack/cmd/license.py
--- a/lib/spack/spack/cmd/license.py
+++ b/lib/spack/spack/cmd/license.py
@@ -22,7 +22,7 @@
 git = which('git')
 
 #: SPDX license id must appear in the first <license_lines> lines of a file
-license_lines = 6
+license_lines = 7
 
 #: Spack's license identifier
 apache2_mit_spdx = "(Apache-2.0 OR MIT)"


Test patch: