Skip to content


Browse files Browse the repository at this point in the history
docs: clarify namespacing when using modules.
  • Loading branch information
johanneskoester committed Mar 16, 2022
1 parent 7c762c7 commit dbed4a3
Showing 1 changed file with 3 additions and 0 deletions.
3 changes: 3 additions & 0 deletions docs/snakefiles/modularization.rst
Expand Up @@ -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`):

Expand Down

0 comments on commit dbed4a3

Please sign in to comment.