From dbed4a3f160106feb15a51d2e8cfcafae531ea57 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johannes=20K=C3=B6ster?= Date: Wed, 16 Mar 2022 09:11:16 +0100 Subject: [PATCH] docs: clarify namespacing when using modules. --- docs/snakefiles/modularization.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/snakefiles/modularization.rst b/docs/snakefiles/modularization.rst index 34c549573..c1e78f20e 100644 --- a/docs/snakefiles/modularization.rst +++ b/docs/snakefiles/modularization.rst @@ -137,9 +137,12 @@ Here, plain paths, HTTP/HTTPS URLs and special markers for code hosting provider The second statement, ``use rule * from other_workflow as other_*``, declares all rules of that module to be used in the current one. Thereby, the ``as other_*`` at the end renames all those rules with a common prefix. This can be handy to avoid rule name conflicts (note that rules from modules can otherwise overwrite rules from your current workflow or other modules). + The module is evaluated in a separate namespace, and only the selected rules are added to the current workflow. Non-rule Python statements inside the module are also evaluated in that separate namespace. They are available in the module-defining workflow under the name of the module (e.g. here ``other_workflow.myfunction()`` would call the function ``myfunction`` that has been defined in the model, e.g. in ``other_workflow/Snakefile``). +Also note that this means that any Python variables and functions available in the module-defining namespace will **not** be visible from inside the module. +However, it is possible to pass information to the module using the ``config`` mechanism described in the following. It is possible to overwrite the global config dictionary for the module, which is usually filled by the ``configfile`` statement (see :ref:`snakefiles_standard_configuration`):