Add bare (no container) install for NCI

[ScottWales]

Add an installation method not using a container at NCI. This can help during package development as all of the Spack builds are on the local filesystem rather than the compute nodes' temporary disks so inspection is easier. It has the downside of installs having a much higher inode count.

To the user the container and bare environments appear exactly the same, in both cases the envrun script will ensure the environment is loaded for a command.

[ScottWales]

Fixed some incompatibilities with using packages built for the container in a bare install. @hiker could you please give the bare install a go and let me know how it goes?

[hiker]

@ScottWales Now I get:

UN spack concretize --fresh
==> Error: cannot load package 'blitz' from the 'ngmo' repository: FilePatch: Patch file fujitsu_compiler_specfic_header.patch for package ngmo.blitz does not exist.

I did a clean rebuild (after previously trying to just update), same effect.

Directory: /scratch/dp9/jxh903/ngmo-envs

[ScottWales]

That's my mess up with git I think - I put some changes in the wrong branch. I've force-pushed a fix, you may need to delete your local branch to pick it up:

git checkout main
git branch -D nci-bare
git checkout nci-bare

[hiker]

I finally got it working (and I also realised that messages from this repo got filtered into the wrong folder, so I didn't notice your answer in time ... apologies).

I do have one problem though: the intel compilers are not in the path. E.g.:

[jxh903@gadi-login-07 ~]$ mpif90 -show
/apps/intel-ct/2021.10.0/compiler/linux/bin/intel64/ifort -I/apps/openmpi/4.1.5/include -I/apps/openmpi/4.1.5/include/Intel -L/apps/openmpi/4.1.5/lib -L/apps/openmpi/4.1.5/lib/Intel -L/system/lib64 -Wl,-rpath=/apps/openmpi/4.1.5/lib -L/apps/intel-oneapi/compiler/2023.2.0/linux/compiler/lib/intel64_lin -Wl,-rpath=/apps/intel-oneapi/compiler/2023.2.0/linux/compiler/lib/intel64_lin -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi

[jxh903@gadi-login-07 ~]$ ifort
bash: ifort: command not found

Fab relies on being able to run the wrapped compiler to make certain versions are consistent (e.g. it verifies that mpif90-ifort does indeed return the same version as ifort, to early detect if e.g. the wrong mpif90 wrapper is being started). Adding the intel compiler to the path fixes this, but I think the plain compilers should be available in the environment.