[sirius] GH200 recipe

[toxa81]

No description provided.

[RMeli]

A few comments, mainly based on comments I received on my recipes. Documentation is currently missing, it should be added to docs/uenv-sirius.md.

[RMeli]

Is it possible to use a released version of Spack (0.22.0 is now out), and add the SIRIUS package in the repo/ folder if needed? I think this is the preferred way to do things.

[bcumming]

This is two topics:

• we should add support for Spack v0.22.0 to stackinator
• a specific commit like this is better than master (because it is more reproducible)
  • but using a tagged release (e.g. v0.21.2) or release branch (e.g. releases/v0.21) is better
  • so moving the sirius package to a repo path is preferable, if possible.

[RMeli]

Suggested change

	views:
	default:
	views:
	sirius:
	link: root

view:link:root is recommended in the docs.

Do you expect users to build SIRIUS from source themselves? If yes, we need a develop view too, where SIRIUS is excluded. This will likely require some tinkering on which specs do you need to add explicitly to the view so that they are available.

It is not yet documented, but the procedure to compile from source should be added to the documentation.

[simonpintarelli]

I'd skip the develop environment here. The "general public" won't build sirius, and those who do will know how to use spack upstream.

[RMeli]

Given the number of root specs (and a few patches) I had to add to #95, I totally agree.

However, from a private conversation with @bcumming it seemed that a develop view is still preferred. I'll let him comment further.

[bcumming]

I have had a bit of a think about this, and how about the following:

The interfaces that you choose to provide (spack, filesystem view, modules) depend on the user community and their needs, and how the uenv maintainer intends to provide support to the users.

If you have a community that only use Spack, then you might not need views or modules for development at all.

If you have some users who will insist on "building their own" using a view or modules, then configure them in a way that will minimise your maintenance burden.

Whatever interfaces are chosen, they should be properly documented in the /docs/<uenv-name>.md docs.