SNAKEMAKE(1)

📦

version 9.21.1 · 5 versions

9.21.1 · fedora 43 (latest)
9.11.4 · fedora 43
9.21.1 · fedora 44
9.16.3 · fedora 44
7.32.4 · debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

💅 snakemake(1) — User Commands 💅

✨ NAME ✨

snakemake — workflow management system to create reproducible and scalable data analyses 🧚

🌸 DESCRIPTION 🌸

okay bestie, first things first, here's literally the entire usage line, every bracket of it, no cap, i'm not skipping a single character because it's all iconic:

usage: snakemake [-h] [--dry-run] [--profile PROFILE]
              [--workflow-profile WORKFLOW_PROFILE] [--cache [RULE ...]]
              [--snakefile FILE] [--cores N] [--jobs N] [--local-cores N]
              [--resources NAME=INT [NAME=INT ...]]  [--set-threads
              RULE=THREADS [RULE=THREADS ...]]  [--max-threads MAX_THREADS]
              [--set-resources RULE:RESOURCE=VALUE [RULE:RESOURCE=VALUE ...]]
              [--set-scatter NAME=SCATTERITEMS [NAME=SCATTERITEMS ...]]
              [--set-resource-scopes RESOURCE=[global|local]
              [RESOURCE=[global|local] ...]]  [--default-resources [NAME=INT
              ...]]  [--preemptible-rules [PREEMPTIBLE_RULES ...]]
              [--preemptible-retries PREEMPTIBLE_RETRIES] [--configfile FILE
              [FILE ...]] [--config [KEY=VALUE ...]]
              [--replace-workflow-config] [--envvars VARNAME [VARNAME ...]]
              [--directory DIR] [--touch] [--keep-going] [--rerun-triggers
              {code,input,mtime,params,software-env}
              [{code,input,mtime,params,software-env} ...]]  [--force]
              [--executor {cluster-generic,local,dryrun,touch}] [--forceall]
              [--forcerun [TARGET ...]]  [--consider-ancient RULE=INPUTITEMS
              [RULE=INPUTITEMS ...]]  [--prioritize TARGET [TARGET ...]]
              [--batch RULE=BATCH/BATCHES] [--until TARGET [TARGET ...]]
              [--omit-from TARGET [TARGET ...]] [--rerun-incomplete]
              [--shadow-prefix DIR] [--strict-dag-evaluation
              {cyclic-graph,functions,periodic-wildcards}
              [{cyclic-graph,functions,periodic-wildcards} ...]]  [--scheduler
              [{greedy,ilp}]] [--conda-base-path CONDA_BASE_PATH]
              [--no-subworkflows] [--precommand PRECOMMAND] [--groups GROUPS
              [GROUPS ...]]  [--group-components GROUP_COMPONENTS
              [GROUP_COMPONENTS ...]]  [--report [FILE]] [--report-after-run]
              [--report-stylesheet CSSFILE] [--report-metadata FILE]
              [--reporter PLUGIN] [--draft-notebook TARGET] [--edit-notebook
              TARGET] [--notebook-listen IP:PORT] [--lint [{text,json}]]
              [--generate-unit-tests [TESTPATH]] [--containerize
              [{dockerfile,apptainer}]] [--export-cwl FILE] [--list-rules]
              [--list-target-rules] [--dag [{dot,mermaid-js}]] [--rulegraph
              [{dot,mermaid-js}]] [--filegraph] [--d3dag] [--summary]
              [--detailed-summary] [--archive FILE] [--cleanup-metadata FILE
              [FILE ...]]  [--cleanup-shadow] [--skip-script-cleanup]
              [--unlock] [--list-changes {params,input,code}]
              [--list-input-changes] [--list-params-changes] [--list-untracked]
              [--delete-all-output | --delete-temp-output] [--keep-incomplete]
              [--drop-metadata] [--version] [--printshellcmds] [--debug-dag]
              [--nocolor] [--quiet [{all,host,progress,reason,rules} ...]]
              [--print-compilation] [--verbose] [--force-use-threads]
              [--allow-ambiguity] [--nolock] [--ignore-incomplete]
              [--max-inventory-time SECONDS] [--trust-io-cache]
              [--max-checksum-file-size SIZE] [--latency-wait SECONDS]
              [--wait-for-free-local-storage WAIT_FOR_FREE_LOCAL_STORAGE]
              [--wait-for-files [FILE ...]] [--wait-for-files-file FILE]
              [--runtime-source-cache-path PATH] [--queue-input-wait-time
              SECONDS] [--omit-flags OMIT_FLAGS [OMIT_FLAGS ...]] [--notemp]
              [--all-temp] [--unneeded-temp-files FILE [FILE ...]]
              [--keep-storage-local-copies] [--not-retrieve-storage]
              [--target-files-omit-workdir-adjustment] [--allowed-rules
              ALLOWED_RULES [ALLOWED_RULES ...]]  [--max-jobs-per-timespan
              MAX_JOBS_PER_TIMESPAN] [--max-status-checks-per-second
              MAX_STATUS_CHECKS_PER_SECOND] [--seconds-between-status-checks
              SECONDS_BETWEEN_STATUS_CHECKS] [--retries RETRIES]
              [--wrapper-prefix WRAPPER_PREFIX] [--default-storage-provider
              DEFAULT_STORAGE_PROVIDER] [--default-storage-prefix
              DEFAULT_STORAGE_PREFIX] [--local-storage-prefix
              LOCAL_STORAGE_PREFIX] [--remote-job-local-storage-prefix
              REMOTE_JOB_LOCAL_STORAGE_PREFIX] [--shared-fs-usage
              {input-output,persistence,software-deployment,source-cache,sources,storage-local-copies,none}
              [{input-output,persistence,software-deployment,source-cache,sources,storage-local-copies,none}
              ...]]  [--scheduler-greediness SCHEDULER_GREEDINESS]
              [--scheduler-subsample SCHEDULER_SUBSAMPLE] [--no-hooks]
              [--debug] [--runtime-profile FILE] [--local-groupid
              LOCAL_GROUPID] [--attempt ATTEMPT] [--show-failed-logs] [--logger
              {} [{} ...]]  [--job-deploy-sources] [--benchmark-extended]
              [--persistence-backend {db,file}] [--persistence-backend-db-url
              PERSISTENCE_BACKEND_DB_URL] [--container-image IMAGE]
              [--immediate-submit] [--jobscript SCRIPT] [--jobname NAME]
              [--software-deployment-method {apptainer,conda,env-modules}
              [{apptainer,conda,env-modules} ...]]
              [--container-cleanup-images] [--use-conda]
              [--conda-not-block-search-path-envvars] [--list-conda-envs]
              [--conda-prefix DIR] [--conda-cleanup-envs] [--conda-cleanup-pkgs
              [{tarballs,cache}]] [--conda-create-envs-only] [--conda-frontend
              {conda,mamba}] [--use-apptainer] [--apptainer-prefix DIR]
              [--apptainer-args ARGS] [--use-envmodules] [--deploy-sources
              QUERY CHECKSUM] [--target-jobs TARGET_JOBS [TARGET_JOBS ...]]
              [--mode {remote,default,subprocess}] [--scheduler-solver-path
              SCHEDULER_SOLVER_PATH] [--max-jobs-per-second
              MAX_JOBS_PER_SECOND] [--cluster-generic-submit-cmd VALUE]
              [--cluster-generic-status-cmd VALUE]
              [--cluster-generic-cancel-cmd VALUE]
              [--cluster-generic-cancel-nargs VALUE]
              [--cluster-generic-sidecar-cmd VALUE]
              [--storage-http-max-requests-per-second [TAG::]VALUE
              [[TAG::]VALUE ...]]  [--storage-http-auth
              [TAG::]AUTH_TYPE=ARG1,ARG2,... [[TAG::]AUTH_TYPE=ARG1,ARG2,...
              ...]]  [--storage-http-allow-redirects [TAG::]VALUE [[TAG::]VALUE
              ...]]  [--storage-http-supports-head [TAG::]VALUE [[TAG::]VALUE
              ...]]  [--storage-s3-max-requests-per-second [TAG::]VALUE
              [[TAG::]VALUE ...]]  [--storage-s3-endpoint-url [TAG::]VALUE
              [[TAG::]VALUE ...]]  [--storage-s3-region [TAG::]VALUE
              [[TAG::]VALUE ...]]  [--storage-s3-access-key [TAG::]VALUE
              [[TAG::]VALUE ...]]  [--storage-s3-secret-key [TAG::]VALUE
              [[TAG::]VALUE ...]]  [--storage-s3-token [TAG::]VALUE
              [[TAG::]VALUE ...]]  [--storage-s3-signature-version [TAG::]VALUE
              [[TAG::]VALUE ...]]  [--storage-s3-retries [TAG::]VALUE
              [[TAG::]VALUE ...]]  [--report-html-path VALUE]
              [--report-html-stylesheet-path VALUE]
              [--scheduler-greedy-greediness VALUE]
              [--scheduler-greedy-omit-prioritize-by-temp-and-input]
              [--scheduler-ilp-solver VALUE] [--scheduler-ilp-solver-path
              VALUE] [targets ...]

Snakemake is a Python based language and execution environment for GNU Makelike workflows. 🐍✨ the way that it just is that, fr fr.

💖 options: 💖

-h, --help — show this help message and exit 🫶 (bestie behaviour honestly)

🔥 EXECUTION 🔥

targets — Targets to build. May be rules or files. 👑
--dry-run, --dryrun, -n — Do not execute anything, and display what would be done. If you have a very large workflow, use --dryrun --quiet to just print a summary of the DAG of jobs. (default: False) — like a lil dress rehearsal, no commitment 💅
--profile PROFILE — okay this one is a whole main character, buckle up 🌈

Profile to use for configuring the Snakemake run with settings regarding the compute environment. Every key in this YAML file gets parsed into the respective command line argument: executor: slurm gets parsed to --executor slurm, default-resources: mem_mb: 16000 is interpreted as --default-resources mem_mb=16000, etc.

You can specify a Snakemake profile as (i) a profile name, (ii) a relative path to a folder or (iii) the relative path to the profile YAML file itself. Snakemake will look for a folder with the profile name or the existence of the relative path in /etc/xdg/snakemake, /builddir/.config/snakemake and the current working directory. Alternatively, you can also specify absolute paths.

If a profile name or folder is given, it has to contain a file profile.yaml (or a config.yaml file, for backwards compatibility). This file can have an optional infix specifying a minimal snakemake version (for example profile.v9+.yaml).

The profile can also be set via the environment variable $SNAKEMAKE_PROFILE. However, once you provide a profile via the command line argument --profile, this environment variable is ignored. And to override this variable without setting another one, provide the value none to this argument.

Finally, you can specify this argument multiple times. In this case, the profiles get merged with the later --profile instances overriding top-level entries in profiles specified earlier. For example, if the last --profile specifies the top level defaultresources: keyword, all entries under that keyword from previous --profiles will be ignored. Similarly, also specifying any of the top-level keys from your profile as a command line argument will overwrite this whole top-level key.

Example profiles for certain compute infrastructure can be obtained at https://github.com/snakemake/snakemake-clusterprofiles. [env var: SNAKEMAKE_PROFILE] 🌟

not me putting the entire profile lore in one flag, but it's giving essential, so here we are 😭

--workflow-profile WORKFLOW_PROFILE — bestie, this is the profile for this specific workflow, like for its resources and stuff. For stuff that's about the compute environment (say, a specific compute cluster), use the global --profiles instead, okay? Generally, an entry like set-resources: a: mem_mb=8 in the YAML file will become --set-resources a:mem_mb=8 for the snakemake run. You can hand over the profile as a file name with a full relative path from the current working directory — in that case the YAML profile file can be named literally whatever you want. In all other cases the folder(s) get searched for a profile.yaml file (or a config.yaml file, for backwards compatibility). This file can have an optional infix specifying a minimal snakemake version (for example profile.v9+.yaml). And any of the following options will always search relative to both the current working directory and the location of the Snakefile: (i) If this option is not provided, the directory profiles/default/ will be searched (and used, if a profile is present; override this implicit usage with --workflow-profile none). (ii) If a profile name is given, the subdirectory of that name under profiles/ will be searched. (iii) If a full relative path is given, this directory will be searched. Settings made in the workflow profile override settings made in the general profile (see --profile) on a per-key basis. Like, if you specify default-resources: in the workflow profile, all default-resources: entries from other profiles get ignored; but if you don't specify defaultresources in your workflow profile, defaultresources from other profiles get passed through. Same energy: specifying any of the toplevel keys from your workflow specific profile via command line arguments will completely overwrite their entries. 💅
--cache [RULE ...] — stores output files of the given rules in a central cache given by the environment variable $SNAKEMAKE_OUTPUT_CACHE. And likewise, it retrieves output files of the given rules from this cache if they've been created before (by literally anybody writing to the same cache), instead of actually executing the rules. Output files are identified by hashing all steps, parameters and software stack (conda envs or containers) needed to create them. If no rules are given, all rules that are eligible for caching (have a cache directive, see docs) are cached. ✨
--snakefile, -s FILE — the workflow definition, in the form of a snakefile. Usually you should not need to specify this, bestie. By default, Snakemake searches for Snakefile, snakefile, workflow/Snakefile, workflow/snakefile beneath the current working directory, in this order. Only if you definitely want a different layout do you need this parameter.
--cores, -c N — use at most N CPU cores/jobs in parallel. If N is omitted or all, the limit is set to the number of available CPU cores. In case of cluster/cloud execution, this argument sets the maximum number of cores requested from the cluster or cloud scheduler. (See https://snakemake.readthedocs.io/en/stable/snakefiles/rules.html#resources-remote-execution for more info.) This number is available to rules via workflow.cores. 🔥
--jobs, -j N — use at most N CPU cluster/cloud jobs in parallel. For local execution this is an alias for --cores (though it's recommended to use --cores in that case, fr fr). Note: set to unlimited to allow any number of parallel jobs.
--local-cores N — in cluster/cloud mode, use at most N cores of the host machine in parallel (default: number of CPU cores of the host). The cores are used to execute local rules. This option is ignored when not in cluster/cloud mode. 🙈
--resources, --res NAME=INT [NAME=INT ...] — define additional resources that shall constrain the scheduling analogously to --cores (see above). A resource is defined as a name and an integer value. E.g. --resources mem_mb=1000. Rules can use resources by defining the resource keyword, e.g. resources: mem_mb=600. If now two rules require 600 of the resource mem_mb they won't be run in parallel by the scheduler. In cluster/cloud mode, this argument will also constrain the amount of resources requested from the server. (See https://snakemake.readthedocs.io/en/stable/snakefiles/rules.html#resources-remoteexecution for more info.) (default: )
--set-threads RULE=THREADS [RULE=THREADS ...] — overwrite thread usage of rules. This lets you finetune workflow parallelization. In particular it's helpful to target certain cluster nodes by e.g. shifting a rule to use more, or less, threads than defined in the workflow. Thereby, THREADS has to be a positive integer, and RULE has to be the name of the rule. (default: )
--max-threads MAX_THREADS — define a global maximum number of threads available to any rule. Rules requesting more threads (via the threads keyword) will have their values reduced to the maximum. This can be useful when you want to restrict the maximum number of threads without modifying the workflow definition or overwriting rules individually with --set-threads. 🎀
--set-resources RULE:RESOURCE=VALUE [RULE:RESOURCE=VALUE ...] — overwrite resource usage of rules. This lets you fine-tune workflow resources. In particular it's helpful to target certain cluster nodes by e.g. defining a certain partition for a rule, or overriding a temporary directory. Thereby, VALUE has to be a positive integer or a string, RULE has to be the name of the rule, and RESOURCE has to be the name of the resource. (default: )
--set-scatter NAME=SCATTERITEMS [NAME=SCATTERITEMS ...] — overwrite number of scatter items of scattergather processes. This lets you fine-tune workflow parallelization. Thereby, SCATTERITEMS has to be a positive integer, and NAME has to be the name of the scattergather process defined via a scattergather directive in the workflow. (default: )
--set-resource-scopes RESOURCE=[global|local] [RESOURCE=[global|local] ...] — overwrite resource scopes. A scope determines how a constraint is reckoned in cluster execution. With RESOURCE=local, a constraint applied to RESOURCE using --resources will be considered the limit for each group submission. With RESOURCE=global, the constraint will apply across all groups cumulatively. By default, only mem_mb and disk_mb are considered local, all other resources are global. This may be modified in the snakefile using the resource_scopes: directive. Note that number of threads, specified via --cores, is always considered local. (See https://snakemake.readthedocs.io/en/stable/snakefiles/rules.html#resourcesremote-execution for more info) (default: )
--default-resources, --default-res [NAME=INT ...] — define default values of resources for rules that do not define their own values. In addition to plain integers, python expressions over inputsize are allowed (e.g. 2*input.size_mb). The inputsize is the sum of the sizes of all input files of a rule. By default, Snakemake assumes a default for mem_mb, disk_mb, and tmpdir (see below). This option lets you add further defaults (e.g. account and partition for slurm) or overwrite these default values. The defaults are mem_mb=min(max(2*input.size_mb, 1000), 8000), disk_mb=max(2*input.size_mb, 1000) (i.e., default disk and mem usage is twice the input file size but at least 1GB), and the system temporary directory (as given by $TMPDIR, $TEMP, or $TMP) is used for the tmpdir resource. The tmpdir resource is automatically used by shell commands, scripts and wrappers to store temporary data (as it is mirrored into $TMPDIR, $TEMP, and $TMP for the executed subprocesses). If this argument is not specified at all, Snakemake just uses the tmpdir resource as outlined above. The tmpdir resource can also be overwritten in the same way as e.g. mem_mb above. Thereby, it's even possible to use shutil.disk_usage(system_tmpdir).free and comparing this to input.size in order to determine if one can expect the system_tmpdir to be big enough and switch to another tmpdir in case it is not. 🧚
--preemptible-rules [PREEMPTIBLE_RULES ...] — define which rules shall use a preemptible machine which can be prematurely killed by e.g. a cloud provider (also called spot instances). This is currently only supported by the Google Life Sciences executor and ignored by all other executors. If no rule names are provided, all rules are considered to be preemptible. 💀
--preemptible-retries PREEMPTIBLE_RETRIES — number of retries that shall be made in order to finish a job from of rule that has been marked as preemptible via the --preemptible-rules setting.
--configfile, --configfiles FILE [FILE ...] — specify or overwrite the config file of the workflow (see the docs). Values specified in JSON or YAML format are available in the global config dictionary inside the workflow. Multiple files overwrite each other in the given order. Thereby missing keys in previous config files are extended by following configfiles. Note that this order also includes a config file defined in the workflow definition itself (which will come first). (default: )
--config, -C [KEY=VALUE ...] — set or overwrite values in the workflow config object. The workflow config object is accessible as variable config inside the workflow. Default values can be set by providing a YAML JSON file (see --configfile and Documentation). Nested values must be defined in Python dict format, e.g., --config "foo={'bar': 42}". 🌸
--replace-workflow-config — so normally when you hand over config files on the command line, they update and extend the workflow's config dictionary. Flip this on and nah bestie, they fully replace it instead. Meaning: any key that isn't spelled out in the config files you provided is now undefined, even if your workflow config totally had it. (default: False)
--envvars VARNAME [VARNAME ...] — environment variables to yeet along to your cloud jobs. ✨
--directory, -d _DIR_ — set your working directory. Any relative paths inside the snakefile will treat this as their origin point. 🎀
--touch, -t — touch the output files (i.e. mark them up to date without actually changing them) instead of running their commands. It's the "pretend the rules ran" move, specifically to fool future invocations of snakemake. It fails if a file doesn't exist yet. Heads up: this only touches files that Snakemake would've recreated anyway (like, because their inputs are newer). If you wanna force a touch, pair it with --force, --forceall, or --forcerun. But ngl, you lose the provenance information once files have actually been created for real. So like… last resort only, fr. (default: False)

💀 Only as a last resort. Provenance is precious.

--keep-going, -k — if a job fails during execution, keep going with the independent jobs anyway. Note: this only covers runtime failures in job execution — not errors during workflow parsing or DAG construction. (default: False)
--rerun-triggers {code,input,mtime,params,software-env} [{code,input,mtime,params,software-env} ...] — define what triggers a job to rerun. By default all the triggers are used, which is what guarantees your results stay consistent with the workflow code and configuration. If you're more into the traditional just-look-at-file-modification-dates vibe, use --rerun-trigger mtime. (default: code input mtime params software-env)
--force, -f — force the execution of the selected target, or the first rule, regardless of whether output already exists. (default: False)
--executor, -e {cluster-generic,local,dryrun,touch} — specify a custom executor, available through an executor plugin: snakemake_executor_<name> 🔥
--forceall, -F — force the execution of the selected (or the first) rule and every rule it depends on, regardless of already created output. (default: False)
--forcerun, -R [TARGET ...] — force the re-execution or creation of the given rules or files. Use this when you changed a rule and want all its output updated in your workflow. 💅
--consider-ancient RULE=INPUTITEMS [RULE=INPUTITEMS ...] — treat given input items of given rules as ancient, meaning they won't trigger re-runs even if they're newer than the output files. Drop this into a workflow-specific profile (or pass it as an argument) and you can overrule rerun triggers caused by file modification dates — for the cases where you, the user, know better. RULE is the name of the rule, INPUTITEMS is a comma separated list of that rule's input items (given as name or as a 0-based index). (default: )
--prioritize, -P TARGET [TARGET ...] — tell the scheduler to give the creation of the given targets (and all their dependencies) the highest priority. 👑
--batch RULE=BATCH/BATCHES — only create the given BATCH of the input files of the given RULE. This is the move for iteratively running parts of absolutely massive workflows — only the execution plan of the relevant part gets calculated, which speeds up DAG computation. Highly recommend you provide the most suitable rule for batching when you document a workflow. It should be some aggregating rule that runs only once and has a large number of input files — like, a rule that aggregates over samples. 🫶
--until, -U TARGET [TARGET ...] — run the pipeline until it reaches the specified rules or files. Only runs jobs that are dependencies of the specified rule or files — it does not run sibling DAGs.
--omit-from, -O TARGET [TARGET ...] — prevent the execution or creation of the given rules or files, plus anything downstream of those targets in the DAG. It also runs jobs in sibling DAGs that are independent of the rules or files you named here.
--rerun-incomplete, --ri — re-run all jobs whose output is recognized as incomplete. (default: False)
--shadow-prefix DIR — specify a directory where the shadow directory gets created. If you don't supply one, the value is set to the .snakemake directory relative to the working directory. 🌸
--strict-dag-evaluation {cyclic-graph,functions,periodic-wildcards} [{cyclic-graph,functions,periodic-wildcards} ...] — strict evaluation of rules' correctness, even when it's not required to produce the output files.
--scheduler [{greedy,ilp}] — pick the scheduling plugin to use. The builtin plugins are greedy (fast) and ilp, and that latter one aims to reduce runtime and hdd usage by using resources as well as possible. (default: ilp)
--conda-base-path CONDA_BASE_PATH — path of your conda base installation (the home of conda, mamba, activate). (internal use only). 🙈
--no-subworkflows, --nosw — don't evaluate or execute subworkflows. (default: False)
--precommand PRECOMMAND — only used in the case of remote execution. This is the command executed before Snakemake runs each job on the remote compute node.
--dag [{dot,mermaid-js}] — don't execute anything, just print the directed acyclic graph of jobs, in either the dot language or in mermaid-js. Recommended use on Unix systems:

snakemake --dag | dot | display

Note that print statements in your Snakefile may interfere with the visualization. 😭

🎀 GROUPING 🎀

--groups GROUPS [GROUPS ...] — assign rules to groups (this overwrites any group definitions that came from the workflow). (default: )
--group-components GROUP_COMPONENTS [GROUP_COMPONENTS ...] — set how many connected components a group is allowed to span. By default that's 1, but this flag lets you extend it. Useful for running, say, 3 jobs of the same rule in the same group even though they're not connected — great for bundling up lots of tiny jobs, or for benefitting from shared memory setups. (default: )

📊 REPORTS 📊

--report [FILE] — create a self-contained HTML report with default statistics, provenance information and user-specified results. For smaller datasets with limited report complexity, you can specify an .html file and all results get embedded directly into it. For customized reports on larger sample sizes, a .zip file makes way more sense — the resulting archive spreads the contents across a folder structure for quicker loading of individual results. You can unpack that archive anywhere and open the report.html file in its main folder to view the report in any web browser. ✨
--report-after-run — after the workflow finishes, go straight to creating the report. Requires you to provide --report. (default: False)
--report-stylesheet CSSFILE — custom stylesheet to use for the report. In particular you can use this for branding the report with, like, a custom logo — see docs. 💅
--report-metadata FILE — custom metadata for the landing page of the report. In particular you can use this to provide metadata in the report, e.g. the work directory — see docs.
--reporter PLUGIN — specify a custom report plugin. By default, Snakemake's builtin html reporter is used. For custom reporters, check out their command line options starting with --report-. 🔍

📓 NOTEBOOKS 📓

--draft-notebook TARGET — draft a skeleton notebook for the rule used to generate the given target file. You can then open that notebook in a jupyter server, run it, and implement it until it's ready. Once saved, Snakemake automatically reuses it in non-interactive mode for subsequent jobs. 🧚
--edit-notebook TARGET — interactively edit the notebook associated with the rule used to generate the given target file. This starts a local jupyter notebook server. Save any changes to the notebook, then stop the server by closing the notebook and hitting the Quit button on the jupyter dashboard. After that, the updated notebook gets automatically stored in the path defined in the rule. If the notebook isn't there yet, this creates an empty draft.
--notebook-listen IP:PORT — the IP address and PORT that the notebook server used for editing the notebook (--edit-notebook) will listen on. (default: localhost:8888)

🛠️ UTILITIES 🛠️

--lint [{text,json}] — perform linting on the given workflow. This prints Snakemake-specific suggestions to improve code quality (work in progress, more lints to be added in the future). If you give no argument, plain text output is used.
--generate-unit-tests [TESTPATH] — automatically generate unit tests for each workflow rule. This assumes all input files of each job are already present. Jobs without present input files get skipped (a warning will be issued). One test case is created per rule, and after successful execution you can run the tests with pytest TESTPATH. 🧪
--containerize [{dockerfile,apptainer}] — print a container definition that provides an execution environment for the workflow, including all conda environments. Supported formats: dockerfile (default), apptainer. 📦
--export-cwl FILE — compile the workflow to CWL and store it in the given FILE.
--list-rules, --list, -l — show the available rules in the given Snakefile. (default: False)
--list-target-rules, --lt — show the available target rules in the given Snakefile. (default: False) 👑
--rulegraph [{dot,mermaid-js}] — okay bestie, this one says do not execute anything and instead prints the dependency graph of rules in dot language or in mermaid-js. It’s less crowded than the DAG of jobs above, but it also shows less information. Note that each rule is displayed once, hence the displayed graph will be cyclic if a rule appears in several steps of the workflow. Use this if the above option leads to a DAG that is too large. Recommended use on Unix systems: snakemake --rulegraph | dot | display. Note print statements in your Snakefile may interfere with visualization. 🦋
--filegraph — do not execute anything and print the dependency graph of rules with their input and output files in the dot language. This is the intermediate bestie between the above DAG of jobs and the rule graph. Note that each rule is displayed once, so the displayed graph will be cyclic if a rule appears in several steps of the workflow. Use this if the above option leads to a DAG that is too large. Recommended use on Unix systems: snakemake --filegraph | dot | display. Note print statements in your Snakefile may interfere with visualization. (default: False) ✨
--d3dag — print the DAG in D3.js compatible JSON format. (default: False) 🔥
--summary, -S — print a summary of all files created by the workflow. It has the following columns: filename, modification time, rule version, status, plan. Thereby rule version contains the version the file was created with (see the version keyword of rules), and status denotes whether the file is missing, its input files are newer or if version or implementation of the rule changed since file creation. Finally the last column denotes whether the file will be updated or created during the next workflow execution. (default: False) 🎀
--detailed-summary, -D — print a summary of all files created by the workflow. It has the following columns: filename, modification time, rule version, input file(s), shell command, status, plan. Thereby rule version contains the version the file was created with (see the version keyword of rules), and status denotes whether the file is missing, its input files are newer or if version or implementation of the rule changed since file creation. The input file and shell command columns are self explanatory. Finally the last column denotes whether the file will be updated or created during the next workflow execution. (default: False) 💖
--archive FILE — archive the workflow into the given tar archive FILE. The archive will be created such that the workflow can be re-executed on a vanilla system. The function needs conda and git to be installed. It will archive every file that is under git version control. Note that it is best practice to have the Snakefile, config files, and scripts under version control. Hence, they will be included in the archive. Further, it will add input files that are not generated by the workflow itself and conda environments. Note that symlinks are dereferenced. Supported formats are <code>.tar</code>, <code>.tar.gz</code>, <code>.tar.bz2</code> and <code>.tar.xz</code>. 🌸
--cleanup-metadata, --cm FILE [FILE ...] — cleanup the metadata of given files. That means that snakemake removes any tracked version info, and any marks that files are incomplete. 🧹
--cleanup-shadow — cleanup old shadow directories which have not been deleted due to failures or power loss. (default: False) 🫶
--skip-script-cleanup — don’t delete wrapper scripts used for execution (default: False) 💅
--unlock — remove a lock on the working directory. (default: False) 🔓
--list-changes, --lc {params,input,code} — list all output files for which the given items (code, input, params) have changed since creation. 👑
--list-input-changes, --li — list all output files for which the defined input files have changed in the Snakefile (e.g. new input files were added in the rule definition or files were renamed). For listing input file modification in the filesystem, use --summary. (default: False) 🌈
--list-params-changes, --lp — list all output files for which the defined params have changed in the Snakefile. (default: False) ⭐
--list-untracked, --lu — list all files in the working directory that are not used in the workflow. This can be used e.g. for identifying leftover files. Hidden files and directories are ignored. (default: False) 🔍
--delete-all-output — remove all files generated by the workflow. Use together with --dry-run to list files without actually deleting anything. Note that this will not recurse into subworkflows. Write-protected files are not removed. Nevertheless, use with care! (default: False)

bestie, this one is serious — it deletes stuff. No cap. 💀

--delete-temp-output — remove all temporary files generated by the workflow. Use together with --dry-run to list files without actually deleting anything. Note that this will not recurse into subworkflows. (default: False) 🧹
--keep-incomplete — do not remove incomplete output files by failed jobs. (default: False) 🙈
--drop-metadata — drop metadata file tracking information after job finishes. Provenance-information based reports (e.g. --report and the --list_x_changes functions) will be empty or incomplete. (default: False) 🫥
--version, -v — show program’s version number and exit 👋

✨ OUTPUT: ✨

--printshellcmds, -p — print out the shell commands that will be executed. (default: False) 💬
--debug-dag — print candidate and selected jobs (including their wildcards) while inferring DAG. This can help to debug unexpected DAG topology or errors. (default: False) 🐛
--nocolor — do not use a colored output. (default: False) 🌑
--quiet, -q [{all,host,progress,reason,rules} ...] — do not output certain information. If used without arguments, do not output any progress or rule information. Defining all results in no information being printed at all. 🤫
--print-compilation — print the python representation of the workflow. (default: False) 🐍
--verbose — print debugging output. (default: False) 📢

💅 BEHAVIOR: 💅

--force-use-threads — force threads rather than processes. Helpful if shared memory (/dev/shm) is full or unavailable. (default: False) 🧵
--allow-ambiguity, -a — don’t check for ambiguous rules and simply use the first if several can produce the same file. This allows the user to prioritize rules by their order in the snakefile. (default: False) 🎯
--nolock — do not lock the working directory (default: False) 🔓
--ignore-incomplete, --ii — do not check for incomplete output files. (default: False) 🙈
--max-inventory-time SECONDS — spend at most SECONDS seconds to create a file inventory for the working directory. The inventory vastly speeds up file modification and existence checks when computing which jobs need to be executed. However, creating the inventory itself can be slow, e.g. on network file systems. Hence, we do not spend more than a given amount of time and fall back to individual checks for the rest. (default: 20) ⏱️
--trust-io-cache — tell Snakemake to assume that all input and output file existence and modification time queries performed in previous dryruns are still valid and therefore don’t have to be repeated. This can lead to speed-ups, but implies that input and output have not been modified manually in between. Non dry-run execution will automatically invalidate the cache and lead to redoing the queries. (default: False) ⚡
--max-checksum-file-size SIZE — compute the checksum during DAG computation and job postprocessing only for files that are smaller than the provided threshold (given in any valid size unit, e.g. 1MB, which is also the default). (default: 1000000) 🔐
--latency-wait, --output-wait, -w SECONDS — wait given seconds if an output file of a job is not present after the job finished. This helps if your filesystem suffers from latency. (default: 5) ⏳
--wait-for-free-local-storage WAIT_FOR_FREE_LOCAL_STORAGE — wait for given timespan for enough free local storage when downloading remote storage files. If not set, no waiting is performed. 💾
--wait-for-files [FILE ...] — wait --latency-wait seconds for these files to be present before executing the workflow. This option is used internally to handle filesystem latency in cluster environments. 👀
--wait-for-files-file FILE — same behaviour as --wait-for-files, but file list is stored in file instead of being passed on the commandline. This is useful when the list of files is too long to be passed on the commandline. Meant for internal use. 📄
--runtime-source-cache-path PATH — path to the runtime source cache directory. Meant for internal use. 📁
--queue-input-wait-time SECONDS — set the interval in seconds to check for new input in rules that use from_queue to obtain input files. (default: 10) 🕒
--omit-flags OMIT_FLAGS [OMIT_FLAGS ...] — omit the given input and output file flags (e.g. pipe). This can be useful for debugging. 🚫
--notemp, --no-temp, --nt — ignore temp() declarations. This is useful when running only a part of the workflow, since temp() would lead to deletion of probably needed files by other parts of the workflow. (default: False) 🔥
--all-temp — mark all output files as temp files. This can be useful for CI testing, in order to save space. (default: False) 🧊
--unneeded-temp-files FILE [FILE ...] — given files will not be uploaded to storage and immediately deleted after job or group job completion. 🗑️
--keep-storage-local-copies — keep local copies of remote input and output files. (default: False) 💾
--not-retrieve-storage — do not retrieve remote files (default is to retrieve remote files). (default: False) ☁️
--target-files-omit-workdir-adjustment — do not adjust the paths of given target files relative to the working directory. (default: False) 📌
--allowed-rules ALLOWED_RULES [ALLOWED_RULES ...] — okay bestie so this one says only look at the rules you name, mmkay? If you don't pass it at all, every rule in the Snakefile gets used. ⚠️ but fr fr this is meant primarily for internal use and can legit do unexpected stuff otherwise. It's an internal/debugging girlie. 🫣
--max-jobs-per-timespan MAX_JOBS_PER_TIMESPAN — The max number of job submissions/executions per timespan. Format is <number><timespan>, like 50/1m or 0.5/1s. (default: 100/1s) ⏱️
--max-status-checks-per-second MAX_STATUS_CHECKS_PER_SECOND — Max number of job status checks per second, and yes fractions are allowed, she contains multitudes. (default: 10) 💅
--seconds-between-status-checks SECONDS_BETWEEN_STATUS_CHECKS — How many seconds to chill between two rounds of status checks. (default: 10) 😌
--retries, --restart-times, -T RETRIES — How many times to restart jobs that fail. Like, give them another chance, they can do it. (default: 0) 🔁
--wrapper-prefix WRAPPER_PREFIX — The URL prefix for the wrapper directive. Set this if you wanna use your own fork or a local clone of the repo — e.g. use a git URL like git+file://path/to/your/local/clone@. 🧬
--default-storage-provider DEFAULT_STORAGE_PROVIDER — Picks the default storage provider used for all input and output files that don't already specify one (think s3). Available storage provider plugins live at https://snakemake.github.io/snakemake-plugin-catalog. If it's not set, or you explicitly pass none, then no default storage provider is used at all. periodt.
--default-storage-prefix DEFAULT_STORAGE_PREFIX — The prefix for that default storage provider. E.g. a bucket name. 🪣
--local-storage-prefix LOCAL_STORAGE_PREFIX — The prefix for storing local copies of storage files and folders (e.g. a local scratch disk). Environment variables will be expanded here. (default: .snakemake/storage) 📁
--remote-job-local-storage-prefix REMOTE_JOB_LOCAL_STORAGE_PREFIX — Same energy as above, but for storing local copies of storage files and folders in the case of remote jobs (e.g. cluster or cloud jobs). Environment variables get expanded within the remote job. (default: .snakemake/storage) ☁️
--shared-fs-usage {input-output,persistence,software-deployment,source-cache,sources,storage-local-copies,none} [{input-output,persistence,software-deployment,source-cache,sources,storage-local-copies,none} ...] — Sets the assumptions about a shared filesystem when you're doing non-local workflow execution. Wanna disable any sharing via the filesystem? Pass none. Usually the executor plugin already sets a correct default, but sometimes it's genuinely worth tuning this — like for optimizing cluster performance. For example, when you're using --default-storage-provider fs together with a cluster executor like slurm, you might want to set --shared-fs-usage persistence software-deployment sources source-cache, so that software deployment and data provenance get handled by NFS, but input and output files get handled exclusively by the storage provider. (default: input-output persistence software-deployment source-cache sources storagelocal-copies) 🗂️
--scheduler-greediness, --greediness SCHEDULER_GREEDINESS — Sets the greediness of scheduling, bestie. This value sits between 0 and 1 and decides how careful the jobs get selected for execution. The default (1.0) gives you the best speed and scheduling quality that's still acceptable. 🚨 deprecated alert — it's deprecated in favor of --scheduler-greedygreediness. (default: 1.0)
--scheduler-subsample SCHEDULER_SUBSAMPLE — Sets the number of jobs to be considered for scheduling. If the number of ready jobs is greater than this value, then this number of jobs gets randomly chosen for scheduling; if the number of ready jobs is lower, this option does literally nothing. Super useful on very large DAGs, where the scheduler can take a lil minute deciding which jobs to run. 🎲
--no-hooks — Do not invoke the onstart, onsuccess or onerror hooks after execution. (default: False) 🙅♀️
--debug — Lets you debug rules with e.g. PDB. This flag is what lets you set breakpoints in run blocks. (default: False) 🐛
--runtime-profile FILE — Profiles Snakemake and writes the output to FILE. Heads up: this requires yappi to be installed. 📊
--local-groupid LOCAL_GROUPID — Internal use only: name for the local groupid. (default: local) 🔒
--attempt ATTEMPT — Internal use only: defines the initial value of the attempt parameter. (default: 1)
--show-failed-logs — Automatically displays the logs of failed jobs. No more digging around yourself, we love convenience. (default: False) 😭
--logger {} [{} ...] — Specify one or more custom loggers, available via logger plugins. (default: ``) 📝
--job-deploy-sources — Whether the workflow sources shall be deployed before a remote job is started. Only applies if --no-sharedfs is set, or if you're using executors that imply no shared FS (e.g. the kubernetes executor). (default: False) 🚀
--benchmark-extended — Write extended benchmarking metrics. (default: False) 📈
--persistence-backend {db,file} — The backend used for Snakemake's metadata persistence. The file backend uses a filesystem directory structure. The db backend uses a relational database via SQLAlchemy. (default: file) 🗄️
--persistence-backend-db-url PERSISTENCE_BACKEND_DB_URL — The database URL to use for the db persistence backend (e.g. sqlite:///.snakemake/metadata.db, postgresql://user@host/db). Only used if --persistence-backend is db. 🔗

🌈 REMOTE EXECUTION 🌈

--container-image IMAGE — The Docker image to use, e.g. when submitting jobs to kubernetes. Defaults to https://hub.docker.com/r/snakemake/snakemake, tagged with the same version as the Snakemake instance you're currently running. Real talk though: overwriting this value is up to your responsibility. Any image you use has to contain a working snakemake installation that is compatible with (or ideally literally the same as) the currently running version. (default: snakemake/snakemake:v9.21.1) 🐳
--immediate-submit, --is — Immediately submits all jobs to the cluster instead of waiting for present input files. ⚠️ This will fail unless you make the cluster aware of job dependencies, e.g. via:

$ snakemake --cluster 'sbatch --dependency {dependencies}'

Assuming your submit script (here sbatch) outputs the generated job id to the first stdout line, {dependencies} will be filled with space separated job ids that this job depends on. Does not work for workflows that contain checkpoint rules, and localrules will be skipped. The additional argument --notemp should be specified. Most often, --notretrieve-storage is also recommended, to avoid Snakemake trying to download output files before the jobs producing them are executed. (default: False) 🏃♀️💨

--jobscript, --js SCRIPT — Provides a custom job script for submission to the cluster. The default script lives as jobscript.sh in the installation directory. 📜
--jobname, --jn NAME — Provides a custom name for the jobscript that gets submitted to the cluster (see --cluster). The wildcard {jobid} has to be present in the name. (default: snakejob.{name}.{jobid}.sh) 🏷️

🧚 SOFTWARE DEPLOYMENT 🧚

--software-deployment-method, --deployment-method, --deployment, --sdm {apptainer,conda,env-modules} [{apptainer,conda,env-modules} ...] — Specify the software environment deployment method. Pick your fighter. 🥊
--container-cleanup-images — Remove unused containers. (default: False) 🧹

🐍 CONDA 🐍

--use-conda — If it's defined in the rule, run the job in a conda environment. If this flag is not set, the conda directive is just ignored, no thoughts head empty. (default: False)
--conda-not-block-search-path-envvars — Do not block environment variables that modify the search path (R_LIBS, PYTHONPATH, PERL5LIB, PERLLIB) when using conda environments. (default: False) 🔓
--list-conda-envs — Lists all conda environments and their location on disk. (default: False) 📋
--conda-prefix DIR — Specify a directory in which the conda and condaarchive directories get created. Those are used to store conda environments and their archives, respectively. If you don't supply it, the value is set to the .snakemake directory relative to the invocation directory. If you do supply it, the --use-conda flag must also be set. The value can be a relative path — which gets extrapolated to the invocation directory — or an absolute path. The value can also be provided via the environment variable $SNAKEMAKE_CONDA_PREFIX. In any case, the prefix may contain environment variables, which will be properly expanded. One more thing: if you use remote execution, e.g. on a cluster, and you have node-specific values for this, you should disable assuming a shared fs for software-deployment (see --shared-fs-usage). 🏠
--conda-cleanup-envs — Cleanup unused conda environments. (default: False) 🧼
--conda-cleanup-pkgs [{tarballs,cache}] — Cleanup conda packages after creating environments. In the case of tarballs mode, it'll clean up all downloaded package tarballs. In the case of cache mode, it'll additionally clean up unused package caches. (default: tarballs) 📦
--conda-create-envs-only — If specified, it only creates the job-specific conda environments and then exits. The --use-conda flag must also be set. (default: False) 🚪
--conda-frontend {conda,mamba} — Choose the conda frontend for installing environments. (default: conda) 🎛️

🦋 APPTAINER/SINGULARITY 🦋

--use-apptainer, --use-singularity — If it's defined in the rule, run the job within an apptainer/singularity container. If this flag is not set, the singularity directive is ignored. (default: False) 🌌
--apptainer-prefix, --singularity-prefix DIR — bestie, this is where your apptainer/singularity images get stashed 💾. If you don't hand over a value, it just defaults to the .snakemake directory relative to the invocation directory. And if you do hand one over, you gotta set the --useapptainer flag too, no exceptions. The value can be a relative path (which gets extrapolated to the invocation directory) or an absolute path. If you don't supply it at all, APPTAINER_CACHEDIR is used. Either way, the prefix can contain environment variables and those get properly expanded, periodt ✨. Heads up tho: if you're doing remote execution, like on a cluster, and you've got node-specific values for this, you should disable assuming a shared fs for software-deployment (peep --shared-fsusage).
--apptainer-args, --singularity-args ARGS — extra args to pass along to apptainer/singularity 🫶.

🌿 ENVIRONMENT MODULES 🌿

--use-envmodules — if it's defined in the rule, run the job inside the given environment modules, loaded in the given order 🧚. You can combine this with --use-conda and --usesingularity, which then only get used as a fallback for rules that don't define environment modules. (default: False)

🔒 INTERNAL 🔒

aka don't touch unless you know what you're doing, bestie 💅

--deploy-sources QUERY CHECKSUM — internal use only: deploy a sources archive from the given storage provider query into the current working subdirectory, and control for the archive checksum before proceeding.
--target-jobs TARGET_JOBS [TARGET_JOBS ...] — internal use only: target particular jobs by RULE:WILDCARD1=VALUE,WILDCARD2=VALUE,...
--mode {remote,default,subprocess} — internal use only: set the execution mode of Snakemake. (default: default)
--scheduler-solver-path SCHEDULER_SOLVER_PATH — internal use only: set the PATH to search for scheduler solver binaries. Deprecated, use --scheduler-ilp-solver-path instead.

💀 DEPRECATED 💀

--max-jobs-per-second MAX_JOBS_PER_SECOND — the maximal number of job submissions/executions per second. Deprecated in favor of --max-jobs-pertimespan. It's giving legacy, ngl 😭.

🔥 cluster-generic executor plugin settings 🔥

--cluster-generic-submit-cmd VALUE — command for submitting jobs 🚀
--cluster-generic-status-cmd VALUE — command for retrieving job status 👀
--cluster-generic-cancel-cmd VALUE — command for cancelling jobs. Expected to take one or more jobids as arguments, no cap.
--cluster-generic-cancel-nargs VALUE — the number of jobids to pass to cancel_cmd. If more are given, cancel_cmd will be called multiple times.
--cluster-generic-sidecar-cmd VALUE — command for the sidecar process 🫡

🌐 http storage plugin settings 🌐

--storage-http-max-requests-per-second [TAG::]VALUE [[TAG::]VALUE ...] — maximum number of requests per second for this storage provider 🏃💨. If nothing is specified, the default implemented by the storage plugin is used. Can be specified multiple times to set different values for different tags.
--storage-http-auth [TAG::]AUTH_TYPE=ARG1,ARG2,... [[TAG::]AUTH_TYPE=ARG1,ARG2,... ...] — HTTP(S) authentication 🔐. AUTH_TYPE is the class name of requests.auth (e.g. HTTPBasicAuth), and ARG1,ARG2,... are the arguments required by the specified type. Can be specified multiple times to set different values for different tags. [env var: SNAKEMAKE_STORAGE_HTTP_AUTH]
--storage-http-allow-redirects [TAG::]VALUE [[TAG::]VALUE ...] — allow redirects when retrieving files 🌈. Can be specified multiple times to set different values for different tags.
--storage-http-supports-head [TAG::]VALUE [[TAG::]VALUE ...] — whether the storage provider supports HTTP HEAD requests 🙋. Can be specified multiple times to set different values for different tags.

🪣 s3 storage plugin settings 🪣

--storage-s3-max-requests-per-second [TAG::]VALUE [[TAG::]VALUE ...] — maximum number of requests per second for this storage provider 🏃💨. If nothing is specified, the default implemented by the storage plugin is used. Can be specified multiple times to set different values for different tags.
--storage-s3-endpoint-url [TAG::]VALUE [[TAG::]VALUE ...] — S3 endpoint URL (if omitted, AWS S3 is used) 🌩️. Can be specified multiple times to set different values for different tags. [env var: SNAKEMAKE_STORAGE_S3_ENDPOINT_URL]
--storage-s3-region [TAG::]VALUE [[TAG::]VALUE ...] — region constraint for the S3 storage 🗺️. Can be specified multiple times to set different values for different tags. [env var: SNAKEMAKE_STORAGE_S3_REGION]
--storage-s3-access-key [TAG::]VALUE [[TAG::]VALUE ...] — S3 access key (if omitted, credentials are taken from .aws/credentials as e.g. created by aws configure) 🔑. Can be specified multiple times to set different values for different tags. [env var: SNAKEMAKE_STORAGE_S3_ACCESS_KEY]
--storage-s3-secret-key [TAG::]VALUE [[TAG::]VALUE ...] — S3 secret key (if omitted, credentials are taken from .aws/credentials as e.g. created by aws configure) 🤫. Can be specified multiple times to set different values for different tags. [env var: SNAKEMAKE_STORAGE_S3_SECRET_KEY]
--storage-s3-token [TAG::]VALUE [[TAG::]VALUE ...] — S3 token (usually not required) 🎟️. Can be specified multiple times to set different values for different tags. [env var: SNAKEMAKE_STORAGE_S3_TOKEN]
--storage-s3-signature-version [TAG::]VALUE [[TAG::]VALUE ...] — S3 signature version ✍️. Can be specified multiple times to set different values for different tags.
--storage-s3-retries [TAG::]VALUE [[TAG::]VALUE ...] — S3 API retries 🔁. Can be specified multiple times to set different values for different tags.

🎀 html report plugin settings 🎀

--report-html-path VALUE — path to the report file (either .html or .zip) 📄. Use zip if your report contains large results or directories with htmlindex as results.
--report-html-stylesheet-path VALUE — path to a custom stylesheet for the report 💅✨

👑 greedy scheduler plugin settings 👑

--scheduler-greedy-greediness VALUE — set the greediness of scheduling 🍰. This value between 0 and 1 determines how careful jobs are selected for execution. The default value (1.0) provides the best speed and still acceptable scheduling quality.
--scheduler-greedy-omit-prioritize-by-temp-and-input — if set, jobs with larger temporary or input files are not prioritized 🙅. The rationale of the prioritization is that temp files should be removed as soon as possible, and larger input files may take longer to process, so it is better to start them earlier.

🧮 ilp scheduler plugin settings 🧮

--scheduler-ilp-solver VALUE — set the MILP solver to use 🧠
--scheduler-ilp-solver-path VALUE — set the PATH to search for scheduler solver binaries 🔍

In general, command-line values override environment variables which override defaults. 🌟

and that's the whole page, bestie — every last flag accounted for, no crumbs left behind 💖

this lil masterpiece is from snakemake 9.21.1, dated June 2026, and it lives at SNAKEMAKE(1) 🦋

go forth and pipeline, you absolute icon 👑

📦 where this page comes from

fedora 43: snakemake 9.21.1-2.fc43 · Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND ISC AND MIT AND MIT-0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-18: a language model's rewrite of the original, under its terms