I'm willing to believe this fixes #719 for this one package; but not for all Python packages, which obviously aren't affected by this PR. Is this a pattern that we should apply to other Python packages? Should we create a PythonPackage base class that incorporates this approach?

So far, I've solved the general problem by spack loading all packages that each Python module depends on.

@citibeth I tried spack load but wasn't able to use it due to a completely unrelated bug (see #1178). Regardless, Spack shouldn't crash when you try to install py-scipy just because you should've installed py-numpy and loaded it first.

@nrichart I really like your solution. If this is a general Python thing them I'm all for incorporating it for all Python modules. Like @citibeth I would like rpaths to work for all Python packages. I wonder if we can use a global site.cfg file. Although that might make deactivating and overwriting tricky.

What is the compiler that has been used to compile py-numpy ? I suspect that we are not using the compiler wrapper, are we?

See PR #543 Toincorporate into all Python modules we can make a
PythonPackcge base class and put the smarts there.
On Jul 7, 2016 12:54 PM, "Adam J. Stewart" notifications@github.com wrote:

@citibeth https://github.com/citibeth I tried spack load but wasn't
able to use it due to a completely unrelated bug (see #1178
#1178). Regardless, Spack shouldn't
crash when you try to install py-scipy just because you should've installed
py-numpy and loaded it first.

@nrichart https://github.com/nrichart I really like your solution. If
this is a general Python thing them I'm all for incorporating it for all
Python modules. Like @citibeth https://github.com/citibeth I would like
rpaths to work for all Python packages. I wonder if we can use a global
site.cfg file. Although that might make deactivating and overwriting tricky.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1188 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AB1cd0S60zlh4C2ZsiNCfRTdrzSAHmAaks5qTS81gaJpZM4JHQta
.

@alalazo The problem occurs when I run spack install py-scipy %gcc@6.1. Everything is built from within Spack, yet py-scipy crashes because it can't find BLAS/LAPACK. I still have to try out @nrichart's change, but it should hopefully allow py-scipy to find them properly.

@nrichart changes will re-add RPATH into py-scipy own build as flags, as far as I can understand. But if RPATHs are not there in the first place, it probably means that py-scipy is not using spack wrappers when it compiles

@alalazo Ah, now I see what you're saying. I can try poking around and seeing if there's some special way to get py-scipy to use the spack wrappers. But if py-scipy isn't using the spack wrappers, then I suspect most Python modules aren't.

In any case, @nrichart's solution does indeed allow me to build py-scipy now!

I believe Setuptools / Distutils has an --rpath option that can be used to
set the RPATH. That is the avenue I would pursue.

On Thu, Jul 7, 2016 at 1:58 PM, Adam J. Stewart notifications@github.com
wrote:

@alalazo https://github.com/alalazo Ah, now I see what you're saying. I
can try poking around and seeing if there's some special way to get
py-scipy to use the spack wrappers. But if py-scipy isn't using the spack
wrappers, then I suspect most Python modules aren't.

In any case, @nrichart https://github.com/nrichart's solution does
indeed allow me to build py-numpy now!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1188 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AB1cd116je_1ba1rz9VL_2JiuWrWSSmXks5qTT42gaJpZM4JHQta
.

I try to check if it is numpy in particular or a general problem. distutils are redefined/extended in the case of numpy to take into account fcompiler that is not part of distutils, py-scipy if I'm not mistaken is using the info from numpy. So this problem might be limited to few packages.

In the case of numpy distutils also add intel compilers.

Regular distutils:

$ python setup.py build --help-compiler 
List of available compilers:
  --compiler=bcpp     Borland C++ Compiler
  --compiler=cygwin   Cygwin port of GNU C Compiler for Win32
  --compiler=emx      EMX port of GNU C Compiler for OS/2
  --compiler=mingw32  Mingw32 port of GNU C Compiler for Win32
  --compiler=msvc     Microsoft Visual C++
  --compiler=unix     standard UNIX-style compiler

numpy's version:

$ python setup.py build --help-compiler
Running from numpy source directory.
List of available compilers:
  --compiler=bcpp      Borland C++ Compiler
  --compiler=cygwin    Cygwin port of GNU C Compiler for Win32
  --compiler=emx       EMX port of GNU C Compiler for OS/2
  --compiler=intel     Intel C Compiler for 32-bit applications
  --compiler=intele    Intel C Itanium Compiler for Itanium-based applications
  --compiler=intelem   Intel C Compiler for 64-bit applications
  --compiler=intelemw  Intel C Compiler for 64-bit applications on Windows
  --compiler=intelw    Intel C Compiler for 32-bit applications on Windows
  --compiler=mingw32   Mingw32 port of GNU C Compiler for Win32
  --compiler=msvc      Microsoft Visual C++
  --compiler=pathcc    PathScale Compiler for SiCortex-based applications
  --compiler=unix      standard UNIX-style compiler

This PR solves the problem for me. I think we should merge it for now and think about adding better RPATH support for Python packages as a whole in some kind of PythonPackage that extends BasePackage (see #1186).

I have also verified that this PR solved some issues when building the python bindings for opencv due to py-numpy openblas issues.

I agree, let's merge. It can only improve things. Good detective work on the blas stuff (it's sad they had to do non-standard Python setuputils stuff for want of a Fortran compiler).