I'm glad that this package has an explicit --rpath flag. However, this won't work for every Python package. I agree with you that a more generic solution would be helpful.

Python packages have 2 problems. Non-Python dependencies aren't being RPATHed properly (as you've noted). See numpy/numpy#8653 for an arguably more important version of this same problem. I am unable to install py-scipy with Spack with Intel MKL because mkl isn't being RPATHed properly when py-numpy is built (even though site.cfg is supposed to have an explicit rpath option).

A second problem is that Python dependencies aren't in sys.path unless they are explicitly added to PYTHONPATH. This means that binaries like sphinx-build and flake8 aren't usable unless all of their dependencies are module loaded as well. There are ways to get around this problem (spack activate, recursive module loading) but neither are ideal.

@citibeth and @wscullin might be interested in this conversation as well. Until a more general solution is devised, I'm going to merge this PR as is.

I am unable to install py-scipy with Spack with Intel MKL because mkl isn't being RPATHed properly when py-numpy is built (even though site.cfg is supposed to have an explicit rpath option).

You need to module load pi-scipy and all its dependencies. spack module loads -r can generate this list.

Unfortunately this won't work. I can't even install py-scipy because it tries to import py-numpy and that fails. Loading the module for py-numpy and openblas won't work either as LD_LIBRARY_PATH is unset. Perhaps we should consider setting LD_LIBRARY_PATH to the same value as we are using for RPATH instead of unsetting it altogether.

It depends on what compiler/BLAS/LAPACK you use. I can build with GCC and OpenBLAS but not Intel and Intel MKL.

Hi @adamjstewart , I'd be interested to know what would happen if you built python without replacing the spack wrappers in the configuration files. That is, comment out the self.filter_compilers command in the post_install method of the python package. If you try installing numpy or scipy, the spack wrappers should set rpath for you. (This may not be the ideal solution to your problem - but it would be nice to know if it works).

That would be nice, but the Spack compiler wrappers can't be used outside of Spack. So I think it would mean that all pip installations would fail. I would have to test it though

Thanks for starting work on #4545, @adamjstewart .

For the record, my idea here was to build python using a fake compiler consisting of a wrapper around the spack wrappers. The outer wrapper would set environment variables equivalent to spack env python, so the real compilers and python dependencies would be defined before calling spack's generic compiler wrappers. Users would need to define LD_LIBRARY_PATH for non-spack dependencies of their packages.

Let's see how #4545 unfolds. We can revisit this "double wrapper" idea if necessary.