Print statements outside of rules are printed each time a rule using "Run" containing a print() statement is executed

[jgriffin-encoded]

Snakemake version
5.30.2 & 6.12.1. I haven't tried others.

Describe the bug

• Print statements outside of any rule seemingly(?) print each time a rule using the "run" directive and containing a print statement is executed.
• Possibly related: In this example below, each time a rule with a run directive is executed the "Job counts" text is also repeated.

Logs

snakemake -s test.smk -j all
I should print once
Building DAG of jobs...
Using shell: /bin/bash
Provided cores: 12
Rules claiming more threads will be scaled down.
Job counts:
        count   jobs
        1       all
        2       run_version
        2       shell_version
        5
...
I should print once
I should print once
Job counts:
        count   jobs
        1       run_version
        1
run directive
Job counts:
        count   jobs
        1       run_version
        1
run directive
...

Minimal example

from pathlib import Path
print("I should print once")

rule all:
    input:
        "A.txt",
        "B.txt",
        "C.csv",
        "D.csv"

rule shell_version:
    output:
        "{sample}.csv"
    shell:
        """
        echo 'Shell directive'
        touch {output}
        """

rule run_version:
    output:
        "{sample}.txt"
    run:
        Path(output[0]).touch()
        print('run directive')

Additional context

[boulund]

I think this is expected considering how Snakemake re-executes the snakefile several times during workflow execution. I have worked around the issue using the onstart handler in my workflows:
https://snakemake.readthedocs.io/en/stable/snakefiles/rules.html#onstart-onsuccess-and-onerror-handlers

Try something like this in your Snakefile:

onstart:
    print("I should print once")

[carruizper]

Do you know how to access any variable created in the onstart handler? I need to execute a function at start and then for it to be available for subsequent rules

[alephreish]

To add to the discussion: this behavior caused a difficult-to-figure-out issue related to variables dependent on timestamps in one of my workflows.