snakefmt
snakefmt copied to clipboard
snakemake
Empty rule keywords raises error
Input:
snakefmt - < assembly.smk
Output:
snakefmt.exceptions.NoParametersError: L124: In input definition.
Check out line 121 of your attached file- input is indeed empty, that doesn't look functional?
I wrote this deliberately to keep the rule names uniform. These rules can be correctly parsed by snakemake.
Having empty rule keywords seems a bit ambiguous. There doesn't seem to be anything in the documentation that explicitly prohibits or allows it. I suspect when snakemake parses it, it just creates an empty list. Would the functionality of your pipeline be affected if you had empty strings in those input statements @alienzj ? As snakefmt will run on this file if there is empty strings in the empty input statements.
We probably need @johanneskoester to comment on whether empty rule keywords is explicitly allow or not.
@mbhall88 The function of the pipeline will not be affected. If the input is empty, the rule will be parsed correctly, but nothing needs to be done during execution.
Ok, well in the meantime, you can add empty strings "" to the input for those rules and snakefmt should format your file.
The fix for this problem is easy to implement code-wise.
However the question is whether the grammar spec for snakemake does allow for the absence of parameters. Although snakemake does in practice, we need to establish if the grammar does. Grammar in https://snakemake.readthedocs.io/en/stable/snakefiles/writing_snakefiles.html states that something like input needs to be followed by parameter_list. This isn't defined in snakemake grammar, and I don't find it verbatim in https://docs.python.org/3/reference/grammar.html. Can parameter_list be nothing, @johanneskoester ?
Technically an empty parameter_list is allowed, as this is indeed supposed to be the same as python function parameters (I believe that at the time when the grammar was written, it was still called parameter_list in the Python grammar). I would usually not suggest to do that though when writing a Snakefile, as it seems unnecessarily verbose.
I'm a little confused here
def f(x, y=):
pass
is not valid python. And this is essentially the crux of the issue I think.
rule a:
input:
b="foo.txt",
c=
is valid snakemake though...If following the python grammar, this should be invalid no?
rule a:
input:
b="foo.txt",
c= # invalid
d=[] # valid
e="" # valid from a syntactical point of view, but will raise an error when evaluating the input files.
rule b:
input: [] # valid
rule c:
input: # I don't really like how this looks like, but it is valid and I won't change it in order to keep backwards compatibility.
output:
"out.txt"
So I guess the question here is if snakefmt should raise an error (as we do in this issue) in the case of rule c's input in your example @johanneskoester? I guess the long-term fix would be not allowing it in snakemake too, but that would be best done with a major version bump to indicate it is backwards incompatible.
The other option is allowing it in snakefmt, which I am quite reluctant to do as it is a major change to the parser...
The example rule a input c relates to #125