| 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 keyword wildcard_constraints can be either a top-level command or a
rule field keyword. The previous order in snakemake-font-lock-keywords
resulted in wildcard_constraints always be highlighted as a command key.
Rearrange the font lock list order to put the field key entry first.
This should result in the correct highlighting in every case except for
when a command key is indented (e.g., under an "if"), but this
presumably will occur much less frequently than wildcard_constraints
being used as a field keyword.
|
|
wildcard_constraints was added in Snakemake v3.8.0 (feb6aee).
|
|
As of Snakemake v3.8.0, using a wildcard rule name signals a key error:
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/snakemake/io.py", line 401, in format_match
value = wildcards[name]
KeyError: 'name'
|
|
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.
|
|
|
|
|
|
Avoid including warnings as targets.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These functions aren't in Emacs 24.* and have been removed from the
emacs-25 branch. See Emacs 124c486 (Remove prog-indentation-context,
2016-03-28).
|
|
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)
|
|
Fixes #17.
|
|
|
|
|
|
Closes #15.
|
|
|
|
|
|
|
|
With introduction of snakemake-graph-this-file, this variable isn't
restricted to rule names.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Used by Travis make call.
|
|
|
|
|