Add tests to Spack
Arbor is distributed among others as Spack package. Spack is an interesting project, it aims be a platform independent (as in, not tied to a particular operating system or Linux distro) package manager. In that it is similar to (home)brew. What’s different is that you’re supposed to formulate any dependencies as dependencies on other Spack packages, such that Spack has a full view of the dependency tree. Spack can build (or concretize) a single environment with all packages that you request, and make sure all dependencies are solved and built in a compatible way. It’s a project started by HPC centers, which can use Spack to build an environment for all its user in a single and reproducible way.
Admirable! And it does work, although the only places I use it is on my local machine when making changes to Arbor’s package.py and testing Arbor over on the Ebrains Lab, which as of earlier this year is building itself through Spack. As part of that project, I need to make the existence of any tests (whatever they are, in our case: some unit tests and executing the examples) known to Spack. This was a bit more complicated than I thought, so I’ll document how I got there. Note: the actual tests were already written.
The Spack documentation is extensive, but that also makes it easy to lose important details in the sea. The documentation often includes log dumps or long examples, which together with sparse headering, makes it difficult to scan a section for something you might need (good example: The “Installing Packages” section. It also took me until today to discover the Tutorial section. Yes, it’s quite prominently placed in the side menu on the main documentation page, but its title “Tutorial: Spack 101” and lack of listed subitems led me to believe this was more of an intro to the conception and basic intended use of Spack, while in actuality, there’s also tons of tutorial material for developers of packages. I suppose a project like Spack needs to communicate to 3 different kinds of audience: users (e.g. scientists requiring a tool at a supercomputer), sysadmins (people who operate the software present at these supercomputers) and tool developers (scientists or software developers who write re-usable software that makes up the repository of tools buildable by Spack).
We will need to make some minor changes to the Arbor repo, so we need to set up Spack so we can work from local source. spack edit arbor will show you the package.py, which might also require modification. This is however the copy that lives in the Spack repo, and contains instructions of where to get Arbor, and we don’t want any release or master branch, we want a local copy where we can make other changes. The Developer workflows Tutorial explains that we do this by setting up a Spack environment (which means Spack must be added to your PATH). Let’s start:
. ~/path/to/spack/share/spack/setup-env.sh # Adding Spack to PATH
mkdir ~/tmp/spacktest
cd ~/tmp/spacktest
spack env create -d .
spacktivate .
spack add arbor
spack install # in my case Arbor was already installed, so nothing needed to be built.
spack develop arbor@master
Now you should find Arbor checkout out in subdirectory arbor, git and all (@master told Spack to get Arbor from the master branch at the git repo after all). After you make any changes in the directory, you can trigger rebuild as follows:
spack concretize -f
spack install
If you want to rebuild, sometimes (especially if you’ve made no changes) it looks like you should remove the build dir, which will look something like spack-build-kw7pxqj.
If you want to run your projects (install-time) tests (e.g. execute make check), then run:
spack install --test=root
Error messages/reports won’t bubble up, so if this fails, see the test output in install-time-test-log.txt.
That’s it! But! After this journey did I discover dev-build, which seems like it’d accomplish the same in fewer steps? I’ll check it out next time I need to make changes.