snakemake: Python 3.12 break f string inside Snakemake
Snakemake version Tested with snakemake 7.34.2 (older version are affected, too. Tested down to 7.18.2)
Affected Python version: 3.12.0 (Last known good: Python 3.11.6)
Describe the bug
When snakemake is installed with python version 3.12.0, f-strings get unexpected extra space.
For example:
output: f'{PREFIX}.txt'
will produce…
Logs
…this output in the log (note the unexpected extra spaces):
Building DAG of jobs...
File path ' SID23454678 .txt ' starts with whitespace. This is likely unintended. It can also lead to inconsistent results of the file-matching approach used by Snakemake.
File path ' SID23454678 .txt ' ends with whitespace. This is likely unintended. It can also lead to inconsistent results of the file-matching approach used by Snakemake.
When run on python 3.12.0
Minimal example
UnitTest.smk:
#!/usr/bin/env python3
PREFIX = 'SID23454678'
rule unit1:
input:
output:
f'{PREFIX}.txt'
run:
"sleep 1"
Running with:
snakemake --dry-run -s UnitTest.smk --cores 1
In this environment… :
mamba create -n snake-test -c conda-forge -c bioconda snakemake-minimal=7.32.4 python=3.11
…everything work as expected:
[Thu Oct 12 15:55:02 2023]
rule unit1:
output: SID23454678.txt
jobid: 0
reason: Missing output files: SID23454678.txt
resources: tmpdir=/tmp
But in that environment…:
mamba create -n snake-test -c conda-forge -c bioconda snakemake-minimal=7.32.4 python=3.12
…the bug is triggered:
Building DAG of jobs...
File path ' SID23454678 .txt ' starts with whitespace. This is likely unintended. It can also lead to inconsistent results of the file-matching approach used by Snakemake.
File path ' SID23454678 .txt ' ends with whitespace. This is likely unintended. It can also lead to inconsistent results of the file-matching approach used by Snakemake.
Additional context
Apparently, the f-string have been completely overhauled as part of python 3.12. I suspect the new f-string parser somehow clashes with the parse of snakemake files.
About this issue
- Original URL
- State: closed
- Created 9 months ago
- Reactions: 8
- Comments: 30 (26 by maintainers)
Commits related to this issue
- Pin Python version - Use Python<=3.12 for now, see snakemake/snakemake#2480 for discussion — committed to vinisalazar/bioconda-recipes by vinisalazar 8 months ago
- Update Metaphor dependencies (#44279) * Pin Python version - Use Python<=3.12 for now, see snakemake/snakemake#2480 for discussion * Bump build number — committed to bioconda/bioconda-recipes by vinisalazar 8 months ago
- fix: handle different f-string tokens in py3.12 (#2485) ### Description fix #2480 ### QC In this fix, f-string such as `f"{any}"` will be formated as `f"{ any }"`. However, f-string suc... — committed to snakemake/snakemake by Hocnonsense 7 months ago
- Restrict Python version until Snakemake bug fix released See https://github.com/snakemake/snakemake/issues/2480 — committed to twrightsman/quantify-RNA-pipeline by twrightsman 7 months ago
The bioconda package has been updated to require python<3.12 until we have fixed this.
I do think so. Before 3.12, tokenize.generate_tokens will yield the whole f-string like f"{PREFIX}.txt". Since 3.12, tokenize.generate_tokens will yield the whole f-string like ‘f"’, ‘{’, ‘PREFIX’, ‘}’, ‘.txt’. ‘"’
This is reporte in pep-0701
Running python 3.12.0 and snakemake 7.32.4, I am seeing the extra spaces in f-strings.
Printed results are:
No, I’m just noticed from your comment, and a more robust fixation for f-string should be make.
The original problem should be fixed, by the pull request that the closing message of this issue cites: https://github.com/snakemake/snakemake/issues/2480#event-11028552730
So, starting with snakemake
8.0.0, the underlying incompatibility with python3.12is fixed, and no workaround should be necessary.Same for snakemake version
7.32.4(from build number1onwards). Here the bioconda recipe has been adjusted to never use python3.12: https://github.com/bioconda/bioconda-recipes/pull/43716/filesFor snakemake version before that, we would have to patch the repodata. Not sure if anybody has done this.
So if I’m not mistaken, the line 1251 should be changed to recognize these new tokens from python 3.12, and not insert spaces around
F_STRING_BEGIN,F_STRING_MIDDLEandF_STRING_ENDtokens?So the key question happened here: https://github.com/snakemake/snakemake/blob/8332d2d28af0900724f7a56aa0e394a99f48d9e0/snakemake/parser.py#L1248-L1254
further test on a simplifier snakefile:
and the key proble happened here:
I test with param “–print-compilation” and that is output:
It is not caused by f-string but snakemake compilation
Haha, you were faster than my screenshot upload. 😃