| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Closes #24.
|
|
|
|
|
|
magit-popup.el is in its own repository as of Magit's 4d5d9bfa
|
|
Subworkflow blocks support a "configfile" field as of Snakemake's
1f02ae9 (Allow to specify configfile for subworkflows., 2016-08-24).
Add "configfile" as a field-key so that the subworkflow variant is
fontified as a key rather than a command. As with "workdir", the
tradeoff is that an indented, non-subworkflow "configfile" is
fontified as a key rather than a command.
Fixes #23.
|
|
|
|
Closes #22.
|
|
Snakemake 4.0.0 requires Python 3.6.
|
|
This function was added in Snakemake v3.10.0.
|
|
|
|
|
|
|
|
To display the graph, snakemake-graph and snakemake-graph-this-file
call image-mode in a buffer with the snakemake graph output. This is
convenient because it works without using an output file, but
displaying the graph fails if Emacs was compiled without ImageMagick
support.
When Emacs doesn't have ImageMagick support, fall back to saving the
file and then displaying it.
|
|
This will allow the graphing commands to save and display the graph
when the user is running an Emacs that was not built with ImageMagick
support.
When the user provides all-blank input or does not confirm an
overwrite, raise a user error so that the caller doesn't have to check
for a nil return value.
|
|
|
|
The primary motivation behind having a terminal interface is that it
works better with tools like Guix because the environment persists
across calls. And the primary reason one would want to use Guix with
Snakemake is so that the dependencies to a workflow/analysis can be
specified and tightly controlled.
However, the user can accidentally step outside of this controlled
environment by running a build command before running
snakemake-term-start. The changes from this mistake can be hard to
confidently reverse and may require a wide removal of output files.
If a user wanted to make sure to only use the Guix-controlled
environment, one approach would be to remove the Snakemake executable
from the environment in which Emacs is started (most likely the
default environment), exposing it only in the workflow environments.
The problem with this is that snakemake.el requires the Snakemake
executable for things like generating lists of targets. Also, it
would be a global change, but a user could reasonably want to control
dependencies with Guix for one project but go through the compile
interface for another.
Add a user option that allows the user to avoid the compile interface
at a global or per-project level.
|
|
|
|
The "-l" flag of "guix environment" doesn't take a manifest; it takes
a file that evaluates to a package or a list of packages.
|
|
|
|
snakemake-build-targets needs to set default-directory to the
Snakefile directory so that snakemake-term-process correctly reports
whether there is an active terminal when the user initiates the call
from a subdirectory.
Conceptually, it also makes sense to handle the directory change in
snakemake-build-targets. The docstrings for the lower-level
snakemake-compile-targets and snakemake-term-build-targets specify
that they correspond to a "snakemake ..." call, which implies that
their caller is responsible for making sure they are called from the
Snakefile directory.
|
|
|
|
|
|
|
|
Snakemake commands are currently executed through compile. In
general, this works fine, but it doesn't work well when Snakemake
should be executed in a different environment than the one in which
the current Emacs session was started. For example, Guix commands
like 'guix environment ...' manipulate environmental variables to
expose particular software. With the current setup, snakemake-program
could be set to a wrapper script that creates the environment and then
calls Snakemake:
guix environment -l manifest.scm --ad-hoc snakemake --pure \
-- snakemake $@
But the disadvantage of this approach is that it adds the
environmental setup time to _each_ Snakemake call.
To work better with tools like Guix, let's add an alternative
interface that allows commands to be executed in a terminal session.
Instead of the above script, snakemake-shell-file-name can be set to a
script with
guix environment -l manifest.scm --ad-hoc snakemake --pure
Now the environmental setup cost is limited to starting the terminal.
|
|
|
|
Make the name and popup description more general so that they still
apply when the terminal interface is added.
|
|
snakemake-compile-targets already takes care of setting
default-directory to the Snakefile directory.
|
|
|
|
|
|
This is in preparation for the addition of a terminal interface. No
code change is intended.
|
|
|
|
This is in preparation for the addition of a terminal interface, at
which point this function will be used beyond the compilation
interface.
|
|
|
|
|
|
As of Emacs 25, single quotes in doc-strings are rendered according to
text-quoting-style, which by default results in single quotes being
displayed as curved quotes. Instead of protecting single quotes with
"\\=", switch some to double quotes (which still need to be escaped,
but in a less jarring way), and avoid quoting symbols, which are
better represented within `'.
|
|
The changes to the first paragraph will make the following commit
cleaner.
Also, there's no need to tell users where to set mmm-global-mode.
|
|
The snakemakepath argument of Workflow was removed in Snakemake
v3.9.1 (062a2e0).
|
|
|
|
|
|
|
|
Using "input" here overrides the highlighting of "input" by
python-font-lock-keywords, although in either case
font-lock-builtin-face is used. The addition of "output" to the
regexp means that output and input are now displayed with a consistent
face in run blocks.
Fixes #20.
|
|
Instead of distinguishing built-ins from field keys by a trailing "(",
make the field key regexp, which is more specific, have a higher
precedence. This allows Snakemake built-ins to be highlighted
correctly even if they are not called as functions.
|
|
The sm-builtin regexp will be extended to support built-in Snakemake
objects like "input" and "output", at which point "function" will no
longer be an accurate description.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|