Add Singularity arguments for specific rules in Snakefile

Create issue
Issue #857 new
Josh Wheaton created an issue

After playing around with singularity and snakemake for awhile, I think it would be nice to have the option to pass specific singularity arguments to individual containers which might be used in separate rules under snakemake. Ideally, this would involve an optional field for each rule in the Snakefile.

The specific use case that comes to mind is setting filesystem bindings for singularity using the "-B" flag. For example, if I am running an aligner out of a container, I might like to give the container access to a locally-stored genome index so that the container (or project directory from which snakemake is run) need not have its own index (which is inefficient in terms of both time and space).

Currently, bindings can be passed to singularity through snakemake by setting the --singularity-args at runtime. i.e.

snakemake --use-singularity --singularity-args "-B <path_to_shared_directory>"

However, this necessitates that all containers deployed in a given Snakefile share the same bindings. I think this should be relatively easy to implement, and would also allow for additional options to be passed to specific containers for diverse future use cases.

Thank you for your consideration!

Comments (6)

  1. Christian Arnold

    I agree that this could be useful, but is it really inefficient to add a few more bindings to a container? Are there any stats for this? If performance is indeed measurably decreased by this, then this is indeed a reasonable feature to ask for.

  2. Michael Hall

    I second this request. For me the use case is a little different though.

    I have a rule that uses a container which I want to run on our GPU cluster. In order to make the GPU hardware accessible to singularity though I need to pass --nv to singularity exec.

    I can obviously do this if the only container I use in my workflow is that container, but I am using multiple containers and therefore don't want to pass this argument to all of them.

  3. Michael Hall

    @johanneskoester I would be happy to try and get this working but maybe need a little guidance.

    If we were wanting to implement this on a per-rule basis presumably this would need to be a new rule parameter (maybe something like singularity_args?). Another option (although it would be a bit more work I guess) would be to have the singularity parameter have known variable names (like resources does) and maybe have some options under the singularity parameter like target (location to container) and args (where we could pass in singularity options such as --nv).

    Option 1

    rule foo:
        input: "file.txt"
        output: "file.out"
        resources:
            mem_mb = 500
        singularity: "container.simg"
        singularity_args: "--nv"
    

    Option 2

    rule foo:
        input: "file.txt"
        output: "file.out"
        resources:
            mem_mb = 500
        singularity: 
            target = "container.simg",
            args = "--nv"
    

    What does everyone else think?

  4. Sebastian Mueller

    I’d also second this request.
    My use-case would also be a potentially external directory congaing a genome index.
    The location of this directory is already saved in a config.yaml as say ref_dir=/path/index and read in the Snakefile as ref_dir = config['ref-dir'], so this could be passed on in the the directive suggested by Michael automatically by something like:

    singularity_args: "--B {ref_dir}" reducing unnecessary user interaction.

  5. Guillaume Barreau

    I have been searching around just yesterday for an option like this until I found this issue. I totally second this as I think it simplifies user interaction.

    I think Option 2 is more readable and more in tune with the rest of the grammar. Though it probably requires more change and makes the current logic invalid.

  6. davide cast

    This is definitely something we need , can also be useful to bind different Homes according to rule.

    Both options are fine in my opinion, thanks.

  7. Log in to comment