vatlab / sos

SoS workflow system for daily data analysis
http://vatlab.github.io/sos-docs
BSD 3-Clause "New" or "Revised" License
274 stars 45 forks source link

SoS Not Registering My Alias for Singularity #1525

Closed alexmccreight closed 1 year ago

alexmccreight commented 1 year ago

After setting an alias (alias singularity="limactl shell Lima apptainer”) to use “singularity” instead of “apptainer”, SoS seems to be referencing the wrong version of singularity. More specifically, when I create a notebook like so:

[default]
bash:
 singularity --version

Then run: sos run mynotebook.ipynb, it yields: “singularity version 3.1.0-196.g8d47ee66.dirty”, when it should show “apptainer 1.2.3”. Thus despite recognizing the 'singularity' command, it's not picking up the established alias. How can I instruct SoS to recognize and use my alias correctly?

BoPeng commented 1 year ago

In this particular case singularity should be whatever in the environment in which sos is running. What is the result of your which singularity?

alexmccreight commented 1 year ago

When I run which singularity in my terminal I get: "singularity: aliased to limactl shell Lima apptainer". However, when I add which singularity to that notebook and do: sos run mynotebook.ipynb I get /usr/local/bin/singularity

BoPeng commented 1 year ago

I think the problem is the use of alias here. SoS uses bash to execute the script (for the run action) but alias are only used in interactive mode, so even bash -i -c 'singularity' would not work (you can try this from your command line).

I suppose instead of an alias, you will have to use apptainer in the script, or create an shell script named singularity instead of an alias.

gaow commented 1 year ago

I suppose instead of an alias, you will have to use apptainer in the script

The problem is that the user's script looks like this:

[default]
bash: container="plink.sif"
 plink

then we run via sos run test.sos which will execute plink from the singularity image. Under the hood SoS would call singularity exec which in this case of a specific user, it would have to be apptainer ... instead of singularity .... It would be good if we can do something at SoS command level without having to change the script.

Of course what you suggested to make a singularity executable script and overwrite the default is also a possibility. @alexmccreight that would be something like

#!/bin/bash
limactl shell Lima apptainer $@

call it singularity as a text file, then chmod +x singularity and put it somewhere the the system loads before your real singularity executable. For example I guess a reasonable place to put it would be your ~/bin -- or whereever the first folder that your echo $PATH command shows on the terminal .

(caution that the script I suggested above may not be the correct syntax but you get the idea -- basically somehting like $@ should direct all that you type after the script to the limactl shell Lima apptainer command. You can try to "dryrun" it by putting in echo limactl shell Lima apptainer add an echo at the beginning so you can test it out and make sure it works as expected)

BoPeng commented 1 year ago

Actually a symbolic link should also work, something like ln -s singularity $(which apptainer)