Update from v0.4.2 to v0.4.3 results in KeyError: 'tex_files_out'
adonath opened this issue · comments
I updated showyourwork
from v0.4.2 to v0.4.3. When I first run the showyourwork build
command I now see the following error:
Traceback (most recent call last):
File "/Users/adonath/github/jolideco/jolideco-paper/.snakemake/scripts/tmpxjag7te0.preprocess.py", line 495, in <module>
config["tree"] = get_json_tree(snakemake.input[0])
File "/Users/adonath/github/my-project/.snakemake/scripts/tmpxjag7te0.preprocess.py", line 411, in get_json_tree
free_floating_graphics = [
File "/Users/adonath/github/my-project/.snakemake/scripts/tmpxjag7te0.preprocess.py", line 414, in <listcomp>
if graphic not in config["tex_files_out"]
KeyError: 'tex_files_out'
When I re-run the showyourwork build
command everything passed as expected. I presume the issue must be related to some caching step. However the same error appears when in the Github actions build, where I cannot easily fix it by re-running.
Related: Is there a way to fix the version of showyourwork
in the action build?
Interesting! In the short term, you may be able to fix the GH Actions workflow using the article-cache-number
argument (https://show-your.work/en/latest/action/) and I'll take a closer look as soon as I can!
When I locally run:
showyourwork clean
showyourwork build
The error appears again. So it is reproducible and I can maybe try to provide a minimal example.
Whoa. Please do - let's try to track this down!
It looks like we don't test for this "floating graphic" feature :/
I think it would be fine and sufficient to just remove this check:
@adonath — Perhaps you could try removing that line in your local installation and see if that does the trick?
In the meantime I started a new project based on v0.4.3 and there is no such error when starting from scratch. For the CI build I was able to fix the issue, just by pinning showyourwork==0.4.2
in the environment.yml
file. So from my side there is no fix required anymore. The issue might just appear in rare circumstance that a repo was created using v0.4.2 and then updated to v0.4.3 in the process. In my case just sticking with v0.4.2. works fine.
Feel free to close @dfm.
Thanks for reporting this update back here, @adonath! I will close, and we can revisit if someone else comes across the issue later.