| Age | Commit message (Collapse) | Author |
|---|
|
public-inbox has started to drop dates from its copyright lines,
pointing to the recommendation at
https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/
I regularly fail to keep copyright lines up to date, so I'll gladly
follow suit.
Drop the dates and change the copyright holder to (almost match) the
variants recommended in the above article.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|