Snakemake version 9.14.1
Describe the bug
I am trying to generate a report and add a Datavzrd table to it. To reference files included in the report from a table column, I add their paths to the data .tsv file using report_href. The report_href function generates a path in the format <long-hash>/file.
However, in the final report folder, Snakemake stores these files using shortened paths (since b24d971). The <long-hash> is replaced by a <short-hash>, and the unused suffix from the original hash is simply dropped. Consequently, when the Datavzrd table tries to reference a file using the original <long-hash>, the link is broken because the actual file on disk uses the <short-hash>.
Currently, it seems there is no built-in method to resolve the correct shortened path. The only workaround appears to be manually determining the length of the <short-hash> and using JavaScript within the HTML page to dynamically reconstruct the correct path from the <long-hash> provided in the table data.
Minimal example
For example, the documented use case with a file like test.html does not work, because in the final report, test.html is stored under a shortened hash path, not the long hash path provided by report_href.
rule a:
input:
report("test.html"),
report(
"subdir",
patterns=["{name}.html"],
)
output:
report(
"test2.html",
)
script:
"test_script.py"
import textwrap
with open(snakemake.output[0], "w") as f:
print(
textwrap.dedent(f"""
<html>
<head>
<title>Report</title>
</head>
<body>
<a href={snakemake.report_href("test.html")}>Link to test.html</a>
</body>
</html>
"""
),
file=f,
)
Additional context
Snakemake version 9.14.1
Describe the bug
I am trying to generate a report and add a Datavzrd table to it. To reference files included in the report from a table column, I add their paths to the data
.tsvfile usingreport_href. Thereport_hreffunction generates a path in the format<long-hash>/file.However, in the final report folder, Snakemake stores these files using shortened paths (since b24d971). The
<long-hash>is replaced by a<short-hash>, and the unused suffix from the original hash is simply dropped. Consequently, when the Datavzrd table tries to reference a file using the original<long-hash>, the link is broken because the actual file on disk uses the<short-hash>.Currently, it seems there is no built-in method to resolve the correct shortened path. The only workaround appears to be manually determining the length of the
<short-hash>and using JavaScript within the HTML page to dynamically reconstruct the correct path from the<long-hash>provided in the table data.Minimal example
For example, the documented use case with a file like
test.htmldoes not work, because in the final report,test.htmlis stored under a shortened hash path, not the long hash path provided byreport_href.Additional context