Issues with external packages via module files instead of path

[davydden]

I tried

packages:
  all:
    compiler: [gcc]
    providers:
      mpi: [openmpi]
      blas: [openblas]
      lapack: [openblas]
  openmpi:
    version: [2.0.1]
    modules:
       openmpi@2.0.1%gcc@4.8.5:  openmpi/2.0.1-gcc
    buildable: False

on a HPC cluster, but get

$ spack install dealii
Traceback (most recent call last):
  File "/spack/bin/spack", line 198, in <module>
    main()
  File "/spack/bin/spack", line 175, in main
    return_val = command(parser, args)
  File "/spack/lib/spack/spack/cmd/install.py", line 317, in install
    specs = spack.cmd.parse_specs(args.package, concretize=True)
  File "/spack/lib/spack/spack/cmd/__init__.py", line 108, in parse_specs
    spec.concretize()  # implies normalize
  File "/spack/lib/spack/spack/spec.py", line 1542, in concretize
    self._expand_virtual_packages(),
  File "/spack/lib/spack/spack/spec.py", line 1459, in _expand_virtual_packages
    spec)
  File "/spack/lib/spack/spack/concretize.py", line 122, in choose_virtual_or_external
    candidates = self._valid_virtuals_and_externals(spec)
  File "/spack/lib/spack/spack/concretize.py", line 83, in _valid_virtuals_and_externals
    externals = spec_externals(cspec)
  File "/spack/lib/spack/spack/config.py", line 489, in spec_externals
    path = get_path_from_module(module)
  File "/spack/lib/spack/spack/build_environment.py", line 149, in get_path_from_module
    modulecmd.add_default_arg('python')
AttributeError: 'NoneType' object has no attribute 'add_default_arg'

[becker33]

@davydden I've never used the module system to find external packages on a non-Cray system (we originally added the feature because it is necessary to cray mpich). Can you paste in the result of module show on the external module you're attempting to load?

[davydden]

@becker33 here's the output

$ module show openmpi/2.0.1-gcc
-------------------------------------------------------------------
/apps/modules/data/development/openmpi/2.0.1-gcc:

module-whatis	sets up the environment for OpenMPI with Intel 64bit compiler
conflict	intelmpi
conflict	mpich
conflict	mpich2
conflict	mvapich
conflict	mvapich2
conflict	necmpi
conflict	openmpi
conflict	intelmpi
prepend-path	PATH	/apps/OpenMPI/2.0.1-gcc/bin
prepend-path	LD_LIBRARY_PATH	/apps/OpenMPI/2.0.1-gcc/lib
prepend-path	LD_RUN_PATH	/apps/OpenMPI/2.0.1-gcc/lib
prepend-path	MANPATH	/apps/OpenMPI/2.0.1-gcc/share/man
setenv		MPIROOTDIR	/apps/OpenMPI/2.0.1-gcc
setenv		MPICHHOME	/apps/OpenMPI/2.0.1-gcc
setenv		MPIHOME	/apps/OpenMPI/2.0.1-gcc
setenv		MPIINCDIR	/apps/OpenMPI/2.0.1-gcc/include
setenv		MPILIBDIR	/apps/OpenMPI/2.0.1-gcc/lib
setenv		MPIINC	-I/apps/OpenMPI/2.0.1-gcc/include
setenv		MPILIB	-L/apps/OpenMPI/2.0.1-gcc/lib
setenv		OMPI_MCA_orte_tmpdir_base	/dev/shm
setenv		OMPI_MCA_btl_openib_warn_default_gid_prefix	0
-------------------------------------------------------------------

I just thought since there are modules already, then it would be easier to set-up external MPI's.

Also don't you need to use modules with Intel compilers to specify which gcc to load? That would be the case regardless of Cray / non-Cray, as far as I understand.

[alalazo]

Is this still an issue?

[davydden]

the behaviour is different now, i see

==> Warning: Could not detect module function from bash. Trying to detect modulecmd from `which`
==> Error: Spack requires modulecmd or a defined module fucntion. Make sure modulecmd is in your path or the function "module" is defined in your bash environment.

but $ module avail works and shows me all modules provided by sysadmins.

[alalazo]

Closing as outdated, as the system to interact with modules changed since the issue was opened.