Adding external intel-mkl makes Spack pick it up ignoring the preferences

[davydden]

happens with

packages:
  all:
    compiler: [clang, gcc]
    providers:
      mpi: [openmpi]
      blas: [openblas]
      lapack: [openblas]
      scalapack: [netlib-scalapack]
   intel-mkl:
     version: [2018.0.128]
     paths:
        intel-mkl@2018.0.128 threads=none: /opt/intel/
     buildable: False

and spack spec dealii. If i just comment intel-mkl in the config, openblas is chosen as expected.

[pramodskumbhar]

Wondering if this is related to discussion in #5110.

[davydden]

@pramodskumbhar : indeed, i forgot that we discussed this. Thanks for remiding

@scheibelp : the use case here is that one would like to have two stacks: one with intel-mkl (external) and one with openblas (internal), So (from #5110)

Spack always replaces a package with an external when one satisfies the constraints,

appears to be a wrong design choice in this context.

EDIT: btw, what shall happen if two mpi are specified externally, probably user preferences should still work.

[davydden]

@scheibelp

do you think that this rule can be changed:

Spack always replaces a package with an external when one satisfies the constraints, so there isn't a consistency error when trying to resolve preferences between externals and non-externals, if that's what you mean. It could be confusing to the user though. The rule is simple enough that IMO it wouldn't be problematic (as long as it's explained up front).

?

I just got into this behaviour yet again when trying to keep two stacks of software locally (one with external intel-mkl and one with openblas). So far, Spack does not really support this, as soon as I add

  intel-mkl:
    version: [2019.0.117]
    variants: threads=none
    paths:
      intel-mkl@2019.0.117 threads=none: /opt/intel/
    buildable: False

then intel-mkl is chosen regardless of my preferences in

packages:
  all:
    providers:
       lapack: [openblas, intel-mkl]

I would say that providers preferences should be satisfied regardless of external/internal packages.

[alalazo]

Outdated by the new concretizer (I believe we still have preferences issues, but this one is tightly related to the old implementation - which is deprecated).