* Updating nalu-wind, nalu, openfast, and tioga packages. Includes
improved handling of +shared variant.
* Add fftw and catalyst support to nalu-wind.
* Restrict ParaView to use matplotlib versions before 3 (which
require Python 3)
* paraview: adding variants to use external packages as internal do not compile
* paraview: add latest paraview version
* catalyst: fixed libvtkexpat undefined reference linking error in Catalyst 5.5
* catalyst: add latest catalyst version
* catalyst: added ParaView_DIR env variable to catalyst module
* add paraview, catalyst patches
- https://gitlab.kitware.com/vtk/vtk-m/merge_requests/1166
- https://gitlab.kitware.com/paraview/paraview/merge_requests/2433
- https://gitlab.kitware.com/paraview/paraview/merge_requests/2436
* - Handle updated library paths for catalyst.
Versions 5.4 and old places libraries under a paraview subdirectory.
Eg, "lib/paraview-5.4", they are now placed directly under "lib"
- Minor code style cleanup
* Handle update library and python paths for ParaView-5.5
* catalyst: added ParaView_DIR path to spack_env
* BUG: applied the patch to the extracted catalyst source files
* paraview: added missing self to a member variable
* paraview: added Paraview_DIR to env
* catalyst: added osmesa variant
* of-catalyst: added new package
* add (FOAM,WM)_PROJECT_DIR also to spack_env environment
* depends on first openfoam release supporting catalyst
* openfoam-com: added missing env variables to module generation
* openfoam: fixed flake8 errors
* of-catalyst: added full variant and openfoam version dependency
* paraview: adding variants to use external packages as internal do not compile
* catalyst: fixed libvtkexpat undefined reference linking error in Catalyst 5.5
* catalyst: added ParaView_DIR env variable to catalyst module
* add paraview, catalyst patches
- https://gitlab.kitware.com/vtk/vtk-m/merge_requests/1166
- https://gitlab.kitware.com/paraview/paraview/merge_requests/2433
- https://gitlab.kitware.com/paraview/paraview/merge_requests/2436
* - Handle updated library paths for catalyst.
Versions 5.4 and old places libraries under a paraview subdirectory.
Eg, "lib/paraview-5.4", they are now placed directly under "lib"
- Minor code style cleanup
* Handle update library and python paths for ParaView-5.5
* catalyst: added ParaView_DIR path to spack_env
* BUG: applied the patch to the extracted catalyst source files
* of-catalyst: added new package
* add (FOAM,WM)_PROJECT_DIR also to spack_env environment
* depends on first openfoam release supporting catalyst
* paraview: added missing self to a member variable
* openfoam-com: added missing env variables to module generation
* openfoam: fixed flake8 errors
* paraview: added Paraview_DIR to env
* catalyst: added osmesa variant
* of-catalyst: added full variant and openfoam version dependency
* paraview-catalyst: use always external expat and netcdf
* of-catalyst: reformatted package description
* paraview-catalyst: removed duplicated function
* catalyst: fixed flake8 error
* of-catalyst: fixed license header
* of-catalyst: minor changes
* of-catalyst: renamed gitrepo with git
* of-catalyst: removed useless gitrepo parameter
- remove the old LGPL license headers from all files in Spack
- add SPDX headers to all files
- core and most packages are (Apache-2.0 OR MIT)
- a very small number of remaining packages are LGPL-2.1-only
* added variant examples to paraview package.py
* qt: added libxt dependency
* add variant to use external hdf5, this is needed when compiling with gcc@4.8.5
* paraview: added python dependecies to PYTHONPATH
* Add the custom paraview lib directory structure to the library paths in the paraview module file.
* Fixing flake8 issues.
* Checking if lib64 exists for paraview module file generation, else use lib.
* Fixing more flake8 problems I introduced.
- paraview 5.2.1 -> 5.4.0 supports both Qt4 and Qt5, but the assumed
default version changes between versions. So explicitly define
which QT major version is being used.
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
- drop old TCL support from paraview build.
- add +plugins variant to have include directories installed. This is
enabled by default since the additional diskspace for includes is
really minimal and since this also allows re-use of the VTK libraries
from ParaView without necessarily requiring a separate VTK
installation.
- +opengl2 is now the default. As per all newer VTK and paraview versions.
BUG: broken install for paraview-5.0.1 with includes and without python
- incorrect conditional for ui_pqExportStateWizard.h when python is
disabled and includes are to be installed.
gcc compiler detection patch.
These have both been fixed in paraview 5.3.0
ENH: refactor as a CMakePackage.
- Note that "spack install paraview" works as expected, but
"spack build paraview" fails in weird unrelated ways.
Spack's HDF5 is too new. Rather than forcing everything in a ParaView
chain to use older HDF5, use the internal one until ParaView is patched
properly.
- This moves var/spack/packages to var/spack/repos/builtin/packages.
- Packages that did not exist in the source branch, or were changed in
develop, were moved into var/spack/repos/builtin/packages as part of
the integration.
Conflicts:
lib/spack/spack/test/unit_install.py
var/spack/repos/builtin/packages/clang/package.py
Package repositories now look like this:
top-level-dir/
repo.yaml
packages/
libelf/
package.py
mpich/
package.py
...
This leaves room at the top level for additional metadata, source,
per-repo configs, indexes, etc., and it makes it easy to see that
something is a spack repo (just look for repo.yaml and packages).
