HAMAP.hmm.gz makes setupdb non-idempotent

[meereeum]

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..