Call for testing: Spack 0.20.2

snap
#1

Hello my snapping friends -

I have recently published a snap for Spack, and, as of yesterday, it has been granted classic confinement; the snap can now successfully be installed from the Snap Store!

To get started with snapped Spack, all you have to do is install it from the Snap Store:

sudo snap install spack --edge --classic

You should then be able to use the snapped Spack as you would normally use Spack on your system. The key difference to note is that I have patched Spack to direct users to enable shell support using custom shell scripts in /etc/spack/shell, rather than using the shell support scripts located in $spack/share/spack. I made these patches because:

  1. I did not want to encourage users to run executables located in /snap/spack/rev-# if they were not defined as apps in snapcraft.yaml.
  2. Prevent the scripts from mutating the users’ PATH environment variable to use the spack executable located in /snap/spack/rev-#/bin/spack, and instead use the predefined spack executable in /snap/bin.

You can view the patch file I created here to see what I specifically changed.

How to start testing

If your interested in helping to test the Spack snap, but you haven’t used Spack much before, check out the Spack tutorial documentation by the Spack community. It’s a great resource for getting started with Spack. If you’re an old pro with Spack, please just use the Spack snap as you would normally use Spack.

With that, happy testing, and please report all issues or suggestions you have as a reply to this post. Let’s make this snap great :rocket::rocket::rocket:

1 Like
#2

Thanks for crafting this snap!

Just curious, are all the prereqs for Spack already included inside the snap? They can be found here:

Also, is the Spack instance pre-bootstrapped, or it will do so at the first invocation of spack spec or spack install?

#3

Hi there! Here are my answers to your questions below:

  1. No, not all the prereqs are installed inside the snap since they would be bound within the mounted read-only loop device when the Spack snap is installed on your system. I purposely made the snap classic so that Spack administrators can provide their own preferred dependencies to Spack. For example, you can use the build-essential package on Debian/Ubuntu systems to fetch the GNU compiler suite. I can add a default set of dependencies to the snap so that you can hit the ground running, but note that will increase the overall footprint/size of the Spack snap.

  2. Spack will be bootstrapped at the first invocation of spack spec or spack install. To be honest, I have thought about pre-bootstrapping Spack in the snap. My big question is where to pre-bootstrap Spack? Should it be done when the snap is first installed by using a configure or install hook? This will make the installation of the snap slower, but you at least won’t need to pre-bootstrap yourself. It could also potentially be done when the snap is built, but I would at least want to know what the trade-offs of this code be. I don’t want to potentially mess up Spack for anyone :sweat_smile:

Let me know if these answer your questions. I am pretty open to adding features to the snap, so let me know if you would like for me to look into pre-bootstrapping Spack within the snap (or if you have any issues with the snap). I’m looking to at least promote the initial rendition of this snap to stable later this week since I haven’t had any issues reported to me yet :grinning_face_with_smiling_eyes:

#4

I think it would be better to bootstrap at install time. You can use spack bootstrap now to perform this. Bootstrapping at snap build time will burn in the system architecture.

1 Like
#5

Sure thing - I can look into adding that feature! You are right about the system architecture if we do it at build time. I was thinking I could spread the spack snap build across various architectures, but I still would not be able to guarantee that I cover all possible architectures that HPC clusters may be using.