Repository: spack/spack

Issue:
serf: scons requires same python for build and run
On a system where the native python is version 2.6, the serf package in spack fails to build. I found that adding a `depends_on('python')` to the serf package fixed the problem, because scons then uses the spack-built `python@2.7` at run-time, matching the version used during installation of scons.

I am not sure why it is necessary to add an explicit dependency on python, when scons is installed as a python package. Shouldn't all python extension packages imply a run-time dependency on python? And similarly for extensions of perl, R, etc.?


Discussion:
I'm not sure why Travis-CI is failing. Possibly a corrupt tar file downloaded from somewhere? No error messages that seem related to the change in this Merge Request.
Closing then reopening to trigger a Travis-CI rebuild
> Shouldn't all python extension packages imply a run-time dependency on python? And similarly for extensions of perl, R, etc.?

Nope. By default, `python`, `perl`, and `r` are listed as dependencies of type `build, link`, meaning that the executable needs to be in the PATH at build time and needs to be added to the compiler wrappers. If a package also needs a dependency to be available at run-time, it needs to declare a `run` type dependency.

Try adding:
```python
depends_on('python', type=('build', 'run'))
```
to the `scons` package and see if that solves your problem. Also, see if `scons` requires Python 2.7 or if it just requires the same version of Python that it was built with.
https://github.com/LLNL/spack/pull/3347 should also resolve this: at the moment run dependencies of build dependencies (i.e. scons->python in this case) are not included in the PATH of the package being built. After that PR is merged, listing python as a build dependency of serf should not be necessary.
Hi @adamjstewart, I tried your suggestion, but it didn't work.

To be more precise, I added `depends_on('python@2.7:2.8', type=('build', 'run'))` to scons, removed the python dependency from serf, then tried to install serf. The error message was identical to my first attempt, indicating that python 2.6 was being used by scons.

But the installation succeeded when I removed the `depends_on('python...` statement from the scons package, loaded the spack python package (2.7.13) in my terminal, then installed serf. Strangely, loading the python package in my terminal only helped after removing the `depends_on('python...` statement from scons. So it seems that using `depends_on` inside a PythonPackage does something, just not what we are expecting.

Do you have any other suggestions that I could try? 
I think #3347 would help, but it may have bigger impacts than some people want. I would be happy with a more limited mechanism that automatically created a dependency on a language package when extension packages are used. For example, scons is a PythonPackage, which should imply a run-time dependency on python (preferably the same version used for installation of scons). The same reasoning would apply to any package that `extends('python')`.
I agree that `PythonPackage` should probably have `depends_on('python', type=('build', 'run'))` in addition to `extends('python')`. Let's try that route instead.

Resolving patch:
diff --git a/lib/spack/spack/build_environment.py b/lib/spack/spack/build_environment.py
--- a/lib/spack/spack/build_environment.py
+++ b/lib/spack/spack/build_environment.py
@@ -259,9 +259,9 @@ def set_build_environment_variables(pkg, env, dirty=False):
     rpath_prefixes      = [dep.prefix for dep in rpath_deps]
 
     # add run-time dependencies of direct build-time dependencies:
-    for bd in build_deps:
-        for rd in bd.dependencies(deptype='run'):
-            build_prefixes.append(rd.prefix)
+    for build_dep in build_deps:
+        for run_dep in build_dep.traverse(deptype='run'):
+            build_prefixes.append(run_dep.prefix)
 
     # Filter out system paths: ['/', '/usr', '/usr/local']
     # These paths can be introduced into the build when an external package


Test patch: