Failures on develop:

@spackbot maintainers

Hi @alalazo! I noticed that the following package(s) don't yet have maintainers:

• elk
• hpcc
• qscintilla

Are you interested in adopting any of these package(s)? If so, simply add the following to the package class:

    maintainers("alalazo")

If not, could you contact the developers of this package and see if they are interested? You can quickly see who has worked on a package with spack blame:

$ spack blame elk

Thank you for your help! Please don't add maintainers without their consent.

You don't have to be a Spack expert or package developer in order to be a "maintainer," it just gives us a list of users willing to review PRs or debug issues relating to this package. A package can have multiple maintainers; just add a list of GitHub handles of anyone who wants to volunteer.

@patrickb314 can you review this PR?

This PR modifies the following package(s), for which you are listed as a maintainer:

• arrayfire
• beatnik
• berkeleygw
• clblast
• hpctoolkit
• ngspice
• octopus
• py-torchgeo

@alalazo I think this is fine for now but we should also make variants, etc. actually work on virtuals. There are design questions there -- like whether they should be passed directly through (e.g., mpi+fortran or mpi+cuda could be quite useful if we just passed the variants through) or should the variants of a virtual be well known and defined on the virtual, e.g., you'd have to explicitly expose and map them on the providers:

# map virtual variants to package variants
# they don't have to be the same but it probably makes sense most of the time.
provides("+cuda", when="+cuda")
provides("fortran", when="+fortran")

I think it's probably the latter. We should merge this for now, but also take note of the removed lines in these packages and try to express what they're saying in the DSL in the long term.

Automatically passing them through would be great. I agree that the virtual variant should probably explicitly map how it passes through. Is there a list of "standard variant names" somewhere?

@patrickb314: no, but this could be one way to formalize them, at least for virtuals. We have talked about having classes for virtual packages, which could act like contracts and allow us to document what the legal variants, versions, etc. are. We don't have that yet so even this is kind of by convention. We could make a page listing all the variants with well known meanings.

We should merge this for now, but also take note of the removed lines in these packages and try to express what they're saying in the DSL in the long term

I agree, and indeed tried to put the same concept briefly in the description. I think we should specify better what virtuals are, and ideally:

1. Define which concrete versions are available for the virtual
2. Define which variants are associated with the virtual

Each implementation can then provide a specific version range and set of variants. Also, each implementation might also be able to provide all the values of a virtual variant with the same installation (e.g. if it installs two different libraries to be used under different circumstances).

We should discuss this, but I suspect we'll end up formalizing having classes for virtual packages too.