From 4be2f9dd9fb41dc169bae068753ceed9552248e7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johannes=20K=C3=B6ster?= Date: Mon, 17 Jul 2023 22:13:58 +0200 Subject: [PATCH] docs: note on using checkpoint mechanism only for input function, not for params or resources. (#2353) ### QC * [x] The PR contains a test case for the changes or the changes are already covered by an existing test case. * [x] The documentation (`docs/`) is updated to reflect the changes or this is not necessary (e.g. if the change does neither modify the language nor the behavior or functionalities of Snakemake). --- docs/snakefiles/rules.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/snakefiles/rules.rst b/docs/snakefiles/rules.rst index 30975bb1b..1d09703d8 100644 --- a/docs/snakefiles/rules.rst +++ b/docs/snakefiles/rules.rst @@ -2191,6 +2191,14 @@ To illustrate the possibilities of this mechanism, consider the following comple "touch {output}" As can be seen, the rule aggregate uses an input function. + +.. sidebar:: Note + + You don't need to use the checkpoint mechanism to determine parameter or resource values of downstream rules that would be based on the output of previous rules. + In fact, it won't even work because the checkpoint mechanism is only considered for input functions. + Instead, you can simply use normal parameter or resource functions that just assume that those output files are there. Snakemake will evaluate them immediately before + the job is scheduled, when the required files from upstream rules are already present. + Inside the function, we first retrieve the output files of the checkpoint ``somestep`` with the wildcards, passing through the value of the wildcard sample. Upon execution, if the checkpoint is not yet complete, Snakemake will record ``somestep`` as a direct dependency of the rule ``aggregate``. Once ``somestep`` has finished for a given sample, the input function will automatically be re-evaluated and the method ``get`` will no longer return an exception.