SPRAS CLI

[tristan-f-r]

Instead of putting everything inside Snakemake, having a wrapping CLI allows for separation of the SPRAS workflow with SPRAS-configuration-generating procedures.

This is important for nondeterminism (we want a way to be able to seed configurations, which is nearly impractical to do within Snakemake) and for tuning (more practical to do in Snakemake, which requires less code, but it's relatively untestable.)

Implemented by #332.

[agitter]

In my meeting with Justin today, we also discussed how a CLI may be useful for later Pelican authorization. It uses a device code flow (e.g. like Docker).

[agitter]

One question I have about the move to a SPRAS CLI is what would happen to all of the Snakemake arguments. Currently, Snakemake is the driver so presumably users could run SPRAS in many custom ways using the many variations Snakemake supports. For example, we're doing this with HTCondor.

[tristan-f-r]

In the implementation, spras run is a transparent call of snakemake that passes all arguments forward. The majority of that PR is styling spras --help.

[tristan-f-r]

Orca has trouble installing conda packages. Packaging SPRAS in a CLI can heavily alleviate the pain of installation there.

[agitter]

Where does the conda problem come from on Orca? It looks like conda/mamba are not preferred but are supported https://orca.pdx.edu/docs/software/python/#virtual-environment-using-mamba

[tristan-f-r]

They are supported. We have too many conda dependencies, so Orca kills conda for hogging too many resources during installation (on the access point).

I've been making an MRE for this, but this entire issue would be circumvented if SPRAS was made easier to install. (You can get around this issue by using uv instead of conda, though this is a clunky solution.)

[tristan-f-r]

Also, this allows us to associate SPRAS with specific versions: we no longer have to do feature freezes before tutorials.

The CLI was also recommended in the original GLBIO FAQ (#32).