| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Initially (7374840), snakemake-check-target only used regular
expressions to detect invalid targets based on the presence of a
MissingRuleException or RuleException in Snakemake's output. The target
was assumed to be valid if these exceptions weren't found. If there was
a non-zero exit status for another reason, it bubbled up to the compile
call where it was visible to the user.
33a7c90 (snakemake-check-target: Adjust for upstream output, 2016-09-01)
restricted the invalid target check to calls with an exit status of
zero. This makes the regular expression check useless because snakemake
should always exit with a non-zero status if a MissingRuleException or
RuleException is thrown. Due to this change, snakemake-check-target
classified all non-zero exits as invalid and all zero exits as valid.
While this often gives the right answer, it doesn't in cases where the
non-zero exit is unrelated to an invalid target.
2bceb7f (snakemake-check-target: Recognize protected items, 2016-09-05)
addressed one case.
To deal with other cases (such as an ambiguous rule error or a syntax
error in the Snakefile), use the following approach.
* An exit status of zero indicates a valid target.
* A non-zero exit status indicates an invalid target if
snakemake-all-rules has an exit status of zero. Otherwise,
snakemake-all-rules will signal an error and display the Snakemake
output.
The main downside of this approach is the need to call snakemake twice.
The output of snakmake-all-rules is cached, so this is only the case on
the first call to snakemake-check-target for a given version of a
Snakefile.
|
|
|
|
|
|
With 33a7c90 (snakemake-check-target: Adjust for upstream output,
2016-09-01), write-protected targets were no longer considered valid
targets.
|
|
The approach from 7b210fc (Ignore standard error stream when digesting
output, 2016-09-01) does not work well because, depending on the
snakemake subcommand, the text of interest may be in the stderr stream.
Instead, use lines with spaces as a way to detect non-target lines.
|
|
|
|
|
|
Include name and block type.
|
|
|
|
|
|
|
|
The previous implementation did not support some legal syntax:
* spaces between rule lines
* indented rule blocks (e.g., a rule defined under an if-statement)
* top-level commands like "include" when the value started on the second
line (re: #16)
|
|
|
|
|
|
|
|
Don't use python-indent-region for indent-region-function. At first
glance, setting indent-region-function to nil (that is, running
indent-according-to-mode on each line) seems to indent rule blocks fine,
though it will probably fail on more complex "run" values.
However, this does mean that python-indent-region is no longer used when
indent-region is called with a region that doesn't include a rule block,
so it's probably worth adding a snakemake-indent-region function that
calls python-indent-region in this case.
Re: #8
|
|
|
|
|
|
|
|
MELPA excludes test.el, tests.el, *-test.el, and *-tests.el.
|