This may or may not be considered an "issue" – but here is a problem I ran into because of a recent change:
prokka build that is part of an automated container workflow, run many times before, started falling down with
SSI index file /opt/conda/envs/myvenv/db/hmm/HAMAP.hmm.h3i already exists;
Delete old hmmpress indices first
Could not run command: hmmpress \/opt\/conda\/envs\/thevenv\/db\/hmm\/HAMAP\.hmm
ERROR conda.cli.main_run:execute(142): `conda run prokka --setupdb` failed. (See above for error)
The reason, I finally realized, being:
$ prokka --setupdb was called as part of the container setup. It turns out this is actually already run during install, at least when installed via conda- HAMAP.hmm recently switched to being distributed as a .gz file that is uncompressed during setup
- so if --setupb is called again, even if preceded by --cleandb, prokka matches both HAMAP.hmm and HAMAP.hmm.gz and complains about the existing .h3i on its second go through the loop
could solve by deduplicating .hmm / .hmm.gz paths during setupdb, clearing a redundant file when cleandb is called, calling hmmpress with -f to forcibly re-generate the index during setupdb, or something else..
This may or may not be considered an "issue" – but here is a problem I ran into because of a recent change:
prokkabuild that is part of an automated container workflow, run many times before, started falling down withThe reason, I finally realized, being:
$ prokka --setupdbwas called as part of the container setup. It turns out this is actually already run during install, at least when installed via condacould solve by deduplicating .hmm / .hmm.gz paths during setupdb, clearing a redundant file when cleandb is called, calling hmmpress with -f to forcibly re-generate the index during setupdb, or something else..