spack/bin/spack

69 lines
2.2 KiB
Text
Raw Normal View History

prefer Python 3 to Python 2 for running Spack The Python landscape is going to be changing in 2020, and Python 2 will be end of life. Spack should *prefer* Python 3 to Python 2 by default, but we still need to run on systems that only have Python2 available. This is trickier than it sounds, as on some systems, the `python` command is `python2`; on others it's `python3`, and RHEL8 doesn't even have the `python` command. Instead, it makes you choose `python3` or `python2`. You can thus no longer make a simple shebang to handle all the cases. This commit makes the `spack` script bilingual. It is still valid Python, but its shebang is `#!/bin/sh`, and it has a tiny bit of shell code at the beginning to pick the right python and execute itself with what it finds. This has a lot of advantages. I think this will help ensure that Spack works well in Python3 -- there are cases where we've missed things because Python2 is still the default `python` on most systems. Also, with this change, you do not lose the ability to execute the `spack` script directly with a python interpreter. This is useful for forcing your own version of python, running coverage tools, and running profiling tools. i.e., these will not break with this change: ```console $ python2 $(which spack) <args> $ coverage run $(which spack) <args> $ pyinstrument $(which spack) <args> ``` These would not work if we split `spack` into a python file and a shell script (see #11783). So, this gives us the best of both worlds. We get to control our interpreter *and* remain a mostly pure python executable.
2019-09-29 03:59:02 +00:00
#!/bin/sh
# -*- python -*-
#
# Copyright 2013-2021 Lawrence Livermore National Security, LLC and other
# Spack Project Developers. See the top-level COPYRIGHT file for details.
#
# SPDX-License-Identifier: (Apache-2.0 OR MIT)
prefer Python 3 to Python 2 for running Spack The Python landscape is going to be changing in 2020, and Python 2 will be end of life. Spack should *prefer* Python 3 to Python 2 by default, but we still need to run on systems that only have Python2 available. This is trickier than it sounds, as on some systems, the `python` command is `python2`; on others it's `python3`, and RHEL8 doesn't even have the `python` command. Instead, it makes you choose `python3` or `python2`. You can thus no longer make a simple shebang to handle all the cases. This commit makes the `spack` script bilingual. It is still valid Python, but its shebang is `#!/bin/sh`, and it has a tiny bit of shell code at the beginning to pick the right python and execute itself with what it finds. This has a lot of advantages. I think this will help ensure that Spack works well in Python3 -- there are cases where we've missed things because Python2 is still the default `python` on most systems. Also, with this change, you do not lose the ability to execute the `spack` script directly with a python interpreter. This is useful for forcing your own version of python, running coverage tools, and running profiling tools. i.e., these will not break with this change: ```console $ python2 $(which spack) <args> $ coverage run $(which spack) <args> $ pyinstrument $(which spack) <args> ``` These would not work if we split `spack` into a python file and a shell script (see #11783). So, this gives us the best of both worlds. We get to control our interpreter *and* remain a mostly pure python executable.
2019-09-29 03:59:02 +00:00
# This file is bilingual. The following shell code finds our preferred python.
# Following line is a shell no-op, and starts a multi-line Python comment.
# See https://stackoverflow.com/a/47886254
""":"
# prefer python3, then python, then python2
for cmd in python3 python python2; do
command -v > /dev/null $cmd && exec $cmd $0 "$@"
done
echo "==> Error: spack could not find a python interpreter!" >&2
exit 1
":"""
# Line above is a shell no-op, and ends a python multi-line comment.
# The code above runs this file with our preferred python interpreter.
from __future__ import print_function
import os
2013-06-02 20:54:46 +00:00
import sys
if sys.version_info[:2] < (2, 6):
v_info = sys.version_info[:3]
sys.exit("Spack requires Python 2.6 or higher."
2016-08-09 20:23:53 +00:00
"This is Python %d.%d.%d." % v_info)
# Find spack's location and its prefix.
spack_file = os.path.realpath(os.path.expanduser(__file__))
spack_prefix = os.path.dirname(os.path.dirname(spack_file))
# Allow spack libs to be imported in our scripts
spack_lib_path = os.path.join(spack_prefix, "lib", "spack")
sys.path.insert(0, spack_lib_path)
# Add external libs
spack_external_libs = os.path.join(spack_lib_path, "external")
add mypy to style checks; rename `spack flake8` to `spack style` (#20384) I lost my mind a bit after getting the completion stuff working and decided to get Mypy working for spack as well. This adds a `.mypy.ini` that checks all of the spack and llnl modules, though not yet packages, and fixes all of the identified missing types and type issues for the spack library. In addition to these changes, this includes: * rename `spack flake8` to `spack style` Aliases flake8 to style, and just runs flake8 as before, but with a warning. The style command runs both `flake8` and `mypy`, in sequence. Added --no-<tool> options to turn off one or the other, they are on by default. Fixed two issues caught by the tools. * stub typing module for python2.x We don't support typing in Spack for python 2.x. To allow 2.x to support `import typing` and `from typing import ...` without a try/except dance to support old versions, this adds a stub module *just* for python 2.x. Doing it this way means we can only reliably use all type hints in python3.7+, and mypi.ini has been updated to reflect that. * add non-default black check to spack style This is a first step to requiring black. It doesn't enforce it by default, but it will check it if requested. Currently enforcing the line length of 79 since that's what flake8 requires, but it's a bit odd for a black formatted project to be quite that narrow. All settings are in the style command since spack has no pyproject.toml and I don't want to add one until more discussion happens. Also re-format `style.py` since it no longer passed the black style check with the new length. * use style check in github action Update the style and docs action to use `spack style`, adding in mypy and black to the action even if it isn't running black right now.
2020-12-23 05:39:10 +00:00
if sys.version_info[:2] <= (2, 7):
sys.path.insert(0, os.path.join(spack_external_libs, 'py2'))
if sys.version_info[:2] == (2, 6):
sys.path.insert(0, os.path.join(spack_external_libs, 'py26'))
sys.path.insert(0, spack_external_libs)
# Here we delete ruamel.yaml in case it has been already imported from site
# (see #9206 for a broader description of the issue).
#
# Briefly: ruamel.yaml produces a .pth file when installed with pip that
2019-05-19 02:00:46 +00:00
# makes the site installed package the preferred one, even though sys.path
# is modified to point to another version of ruamel.yaml.
if 'ruamel.yaml' in sys.modules:
del sys.modules['ruamel.yaml']
if 'ruamel' in sys.modules:
del sys.modules['ruamel']
import spack.main # noqa
2020-11-12 20:26:23 +00:00
# Once we've set up the system path, run the spack main method
if __name__ == "__main__":
sys.exit(spack.main.main())