Configuration scopes and placement of packages.yaml

[tmadlener]

In fact this is more an issue for key4hep-doc, but issues are not enabled there, so I am posting it here, also because this might be the first thing people consult when running into the same problem as I just did.

The issue

Following the instructions, the config/packages.yaml should be placed in spack/etc/spack/. However, this can lead to problems, especially if users have a user level packages.yaml configuration in ~/.spack/. The reason is that this user level configuration settings take precedence over the settings that ship with this. See: configuration scopes.

The problem I am currently running into, is that I have a

packages:
  all:
    variants: cxxstd=17

in my user configuration which interferes, with the currently shipped packages.yaml, leading to an unsatisfiable variant constraint:

Input spec
--------------------------------
 -   key4hep-stack

Concretized
--------------------------------
==> Error: An unsatisfiable variant constraint has been detected for spec:

    clhep@2.4.4.0%gcc@9.3.0~ipo build_type=RelWithDebInfo cxxstd=17 arch=linux-ubuntu20.04-broadwell


while trying to concretize the partial spec:

    geant4@10.7.0%gcc@9.3.0~ipo~motif~opengl~python~qt+threads+vecgeom~x11 build_type=RelWithDebInfo cxxstd=11 arch=linux-ubuntu20.04-broadwell
        ^cmake@3.16.3%gcc@9.3.0~doc+ncurses+openssl+ownlibs~qt arch=linux-ubuntu20.04-broadwell
        ^expat@2.2.9%gcc@9.3.0+libbsd arch=linux-ubuntu20.04-broadwell
            ^libbsd
        ^geant4-data@10.7.0
            ^g4abla@3.1
            ^g4emlow@7.13
            ^g4ensdfstate@2.3%gcc@9.3.0 arch=linux-ubuntu20.04-broadwell
            ^g4incl@1.0
            ^g4ndl@4.6
            ^g4particlexs@3.1
            ^g4photonevaporation@5.7
            ^g4pii@1.3
            ^g4radioactivedecay@5.6
            ^g4realsurface@2.2
            ^g4saiddata@2.0
        ^zlib@1.2.11%gcc@9.3.0+optimize+pic+shared arch=linux-ubuntu20.04-broadwell


geant4 requires clhep variant cxxstd=11, but spec asked for cxxstd=17

The problem can be solved in several different ways in this case, and is in fact most probably caused by the spack concretizer (so should be less severe in the future, hopefully). The underlying problem is that geant4 defines some desired variants

key4hep-spack/config/packages.yaml

Lines 26 to 27 in f29e6ce

	geant4:
	variants: ~qt~opengl+vecgeom

Apparently, the cxxstd=17 variant is not added to this, even it should be for all packages. Hence only clhep gets the cxxstd=17 requirements from the user level configuration, which in turn leads to the above error.

Immediate solutions:

• add cxxstd=17 to the variants of geant4 in the packages.yaml that we ship here
• remove the cxxstd=17 variant from the packages: all section in the user level packages.yaml

Open questions:

Should we consider updating the instructions to install the shipped packages.yaml somewhere, where it takes precedence over user settings to ensure that we have a consistent build everywhere regardless of user settings?

[vvolkl]

That's strange, I would have expected that your setting of the cxxstd would be applied to geant4. This could be a bug in spack. For the immediate solution, I think nothing speaks against using cxxstd=17 for geant4 (or actually all packages like you do)

Regarding the interference from ~/.spack/, the same problem applies to .bashrc and other ways people can change their system. I think it should be documented, but having the possiblity to configure spack is also a feature.

Note that now also spack is installed on cvmfs for a "just works"-type setup (although the same precedence considerations apply)

[tmadlener]

That is indeed a good point about spack seemingly not applying the "global" cxxstd variant to geant4. I will check if this is indeed a spack bug (see spack/spack#20936).

Regarding the interference from ~/.spack/, the same problem applies to .bashrc and other ways people can change their system. I think it should be documented, but having the possiblity to configure spack is also a feature.

Yeah, I agree. So we should document this. I will open a pull request for the key4hep-doc.