Handling equivalent file extensions in Snakemake

Question

Essentially, I want to know what the recomended way of handling equivalent file extensions is in snakemake. For example, lets say I have a rule that counts the number of entries in a fasta file. The rule might look something like....

rule count_entries:
    input:
        ["{some}.fasta"]
    output:
        ["{some}.entry_count"]
    shell:
        'grep -c ">" {input[0]} > {output[0]}'

This works great. But what if I want this rule to also permit "{some}.fa" as input?

Is there any clean way to do this?

EDIT:

Here is my best guess at the first proposed sollution. This can probably be turned into a higher order function to be more general purpose but this is the basic idea as I understand it. I don't think this idea really fits any general use case though as it doesn't cooperate with other rules at the "building DAG" stage.

import os

def handle_ext(wcs):
    base = wcs["base"]
    for file_ext in [".fasta", ".fa"]:
        if(os.path.exists(base + file_ext)):
            return [base + file_ext]

rule count_entries:
    input:
        handle_ext
    output:
        ["{base}.entry_count"]
    shell:
        'grep -c ">" {input[0]} > {output[0]}'

EDIT2: Here is the best current sollution as I see it...

count_entries_cmd = 'grep -c ">" {input} > {output}'
count_entries_output = "{some}.entry_count"

rule count_entries_fasta:
    input:
        "{some}.fasta"
    output:
        count_entries_output
    shell:
        count_entries_cmd

rule count_entries_fa:
    input:
        "{some}.fa"
    output:
        count_entries_output
    shell:
        count_entries_cmd

Answer 1

One thing I noticed is that you are trying to specify lists of files in both input and output sections but actually your rule takes a single file and produces another file. I propose you a straightforward solution of specifying two separate rules for different extensions:

rule count_entries_fasta:
    input:
        "{some}.fasta"
    output:
        "{some}.entry_count"
    shell:
        'grep -c ">" {input} > {output}'

rule count_entries_fa:
    input:
        "{some}.fa"
    output:
        "{some}.entry_count"
    shell:
        'grep -c ">" {input} > {output}'

These rules are not ambiguous unless you keep files with the same {some} name and different extension in the same folder (which I hope you don't do).

Answer 2

One possible solution is to only allow the original rule to take .fasta files as input, but enable .fa files to be renamed to that. For example,

rule fa_to_fasta:
    input:
        "{some}.fa"
    output:
        temp("{some}.fasta")
    shell:
        """
        cp {input} {output}
        """

Clearly this has the disadvantage of making a temporary copy of the file. Also, if foo.fa and foo.fasta are both provided (not through the copying), then foo.fasta will silently overshadow foo.fa, even if they are different.

Answer 3

Even though OP has edited his entry and included the possible workaround via the input functions, I think it is best to list it also here as an answer to highlight this as possible solution. At least for me, this was the case :)

So, for example if you have an annotation table for your samples, which includes the respective extensions for each sample-file (e.g. via PEP), then you can create a function that returns these entries and pass this function as input to a rule. My example:

# Function indicates needed input files, based on given wildcards (here: sample) and sample annotations
# In my case the sample annotations were provided via PEP
def get_files_dynamically(wildcards):
    sample_file1 = pep.sample_table["file1"][wildcards.sample]
    sample_read2 = pep.sample_table["file"][wildcards.sample]

    return {"file1": sample_file1, "file2": sample_file2}


# 1. Perform trimming on fastq-files
rule run_rule1:
    input:
        unpack(get_files_dynamically) # Unpacking allows naming the inputs
    output:
        output1="output/somewhere/{sample}_1.xyz.gz",
        output2="output/somewhere/{sample}_2.xyz.gz"
    shell:
        "do something..."