Issue on E4S page: Get E4S

[maherou]

Please describe the problem with this page:

https://E4S-Project.github.io/get/

I have created a new page (reachable from this page) that describes how to create a local cache-backed E4S container. I used GitHub Copilot to create the new page and integrate it into the website.

I would appreciate a review of this page and https://e4s.io/create-local-e4s-binary-cache/ by experts to see if the instructions are clear and accurate

[eugeneswalker]

Are these instructions meant to help an end user build a custom container image with only a subset of E4S packages of interest to them? If so, would it be better to describe how they might take advantage of pre-existing E4S build cache? If the end-user truly wants to make their own E4S build cache on local filesystem, would we want to instruct them on how to do this using one of our model environments (which are tested in CI) that they adapt for their purposes instead of illustrating the process with the environment currently shown in the linked page? What do you think @wspear?

[wspear]

In it's current state I'm concerned this is more of an e4s-branded Spack tutorial since, as Luke noted, it doesn't leverage any artifacts of an E4S release.

Unless or until packages in the binary repo can reliably be installed on arbitrary systems all we have for end user builds is our spack.yaml files which should be the starting point, but those mostly don't specify versions or variants. I propose another official release artifact for E4S: a concretized environment spec for all top level e4s packages. This would let someone build their own binary repo targeting exactly the same package versions and variants e4s is using (therefore actually benefiting from our testing) and should be very easy to generate.

[maherou]

I want users to be able to create their own local build cache from E4S-curated versions of some or all of the products E4S supports.

I think there are many users who would like to rely on E4S-curated versions of products but don't want to trust our online build cache, or simply aren't permitted to do so.

I am trying to provide a simple guide for them to select the products in an E4S release (which could be all of them) and then build them in their local environment to create a local binary cache. The key difference between this workflow and the general instructions for creating a local Spack build cache is that it uses E4S versions of products.

I hope my description makes sense. Please let me know. Also, this effort was, in part, an experiment to see whether GitHub could generate the page from the English-language description. That went quite smoothly.

[wspear]

I ran through the instructions and there are a couple technical issues with the demo as constructed.

First, it says to run spack env activte before the spack.yaml file is created. Without a spack.yaml file in the target directory, spack env activate will fail. Those need to be switched.

Second, spack install doesn't recognize a -b argument. --cache-only does exist and will force installation from binary mirrors only.

Non-fatal, issues:

I don't think -d is necessary for spack env activate. Just spack env activate . should work.

The example path, file:///sw/spack/mirror/e4s-local is a little confusing. Maybe use $HOME or pwd as the base just so its clear what syntax is happening there (/sw may not register is a local file path at a glance)

I didn't test this with a separate spack install, just a different environment, so it didn't actually do much. But building out the example a bit to show explicitly how to verify the repo is working on a second install might be worth while.

[eugeneswalker]

I want users to be able to create their own local build cache from E4S-curated versions of some or all of the products E4S supports.

I think there are many users who would like to rely on E4S-curated versions of products but don't want to trust our online build cache, or simply aren't permitted to do so.

This makes total sense. Thank you for clarifying.

I am trying to provide a simple guide for them to select the products in an E4S release (which could be all of them) and then build them in their local environment to create a local binary cache. The key difference between this workflow and the general instructions for creating a local Spack build cache is that it uses E4S versions of products.

Got it. Yes. We will need to include information about how to (1) get the model E4S Spack environment from our public repo and (2) adapt the environment so that builds are configured appropriately for the target system.