assembly mags Bakta encode/decode error

[microbemarsh]

When trying to test out the assembly_mags subworkflow with the SRA zymo samples (ones used in the bakeoff paper) the program errored out with the following.

Command exit status:
  1

Command output:
  Bakta v1.11.4
  Options and arguments:
  	input: /dodo/am503/Somatem/work/dd/cad486bd411765b7832f9ec7096a09/mock20_hiq100k/output_bins/SemiBin_0.fa.gz
  	db: /home/dbs/bakta_db/db, version 6.0, full
  	
.... more stuff ...

File "/dodo/am503/micromamba/other-envs/env-a8006fb594b943adc55c130fa07e500c/lib/python3.11/site-packages/bakta/features/orf.py", line 25, in detect_spurious
      orf = orf_by_aa_digest[hit.name.decode()]
                             ^^^^^^^^^^^^^^^
  AttributeError: 'str' object has no attribute 'decode'. Did you mean: 'encode'?

Work dir:
  /dodo/am503/Somatem/work/e7/47ac02624e085bb29a8dedc38f6f7e

full info at: assembly_mags_bakta_error_nextflow.log

• This occurred after I had made changes to singlem version in the environment.yml and changed the path to the singlem db in the nextflow.config.
• The run kept crashing at that step due to dbs (but lets figure that out later). since I used a manually downloaded DB instead.
• Here is the singlem pipe environment.yml that led it to work for me (in agm_assem branch too) ; using this new_agm_singlem_environment.yml on path modules/local/singlem/pipe/environment.yml

name: singlem_pipe
channels:
  - conda-forge
  - bioconda
  - defaults
channel_priority: strict # why strict?
dependencies:
  - singlem=0.20.3

## found in the branch>might be a newer version of testing?
dependencies:
#  - singlem=0.20.3 # old version: needed to downgrade to work?
  - python=3.12
  - singlem=0.19.0
  - tqdm=4.66.5

I attempted the fix here oschwengers/bakta#424 but to no avail.

All testing was performed on branch agm_assem publishing for debugging right after this is posted.

[microbemarsh]

I changed the wrong yaml file, shouldn't matter for the bakta db download but now I've updated the local bakta module (what actually runs bakta) and Im testing it out to see if this downgrade to pyhmmer=0.11.4 fixes the issue. If tests prove that to be true I'll then push that change to this branch after.

[ppreshant]

Plan to debug/fix this issue

Steps 1-3 below are relevant: Will transcribe this to text later (for searchability!)

1. Bakta version 1.11.4 is consistent between the failed agm run and the successful PK run (confident_stone nickname). So it must be a newer version of some other dependency that broke.
2. TBD
3. Try using the locked spec file here (/home/Users/pbk1/Somatem/archive/bakta_env-confident_stone.txt) with these commands

## cd into your work dir for the bakta process:
cd /dodo/am503/Somatem/work/e7/47ac02624e085bb29a8dedc38f6f7e

# create a new env with the locked specs
micromamba create -n bakta_test -f /home/Users/pbk1/Somatem/archive/bakta_env-confident_stone.txt

# activate and run the .command.sh within the work dir

4. Can export your problem environment's locked spec file and compare with above? ref: user guide

[microbemarsh]

Fixed the issue! The updated yaml was not making a new environment hence the same error...

Changed the pyhmmer version in the existing conda env to v0.11.4 and that fixed the string encode/decode error.

Now just onto the amrfinderdb error...

[microbemarsh]

Updated the amrfinderdb at /home/dbs/bakta_db/db/amrfinderplus-db using amrfinder_update --force_update --database /home/dbs/bakta_db/db/amrfinderplus-db in the bakta env from Somatem. This allowed bakta finish completely and for the mag assembly pipeline to finally succeed (in the agm_assem branch @ppreshant )!

Completed at: 04-Mar-2026 10:24:08
Duration    : 18m 17s
CPU hours   : 19.8 (27.7% cached)
Succeeded   : 6
Cached      : 17

[ppreshant]

Great news! Just noticed that you fixed this.

1. I want to test out the bakta-pyhmmr issue on my end before merging this to main;

• Does it suffice to hide my bakta env and let conda rebuild it from your new yaml in your branch?

2. I'll check the code of your branch and try to recall what this amrfinderplus-db thing is. If this wasn't used before and is new, I might need to make a downlaod module for this as well

[microbemarsh]

I think if you build a new conda env from this branch the issue should go away. Really the only thing needed for bakta is limiting the pyhmmer version to 0.11.4 or lower.

As to the amrfinderplus-db error, I think there was some updates to amrfinderplus such that when building a fresh conda env it wants an updated database as well. This is a hypothesis but I do know there was some recently released databases for it.

[ppreshant]

Bakta

I noticed that Bakta is available so I suggest moving to nf-core for [Bakta](https://nf-co.re/modules/bakta_bakta/). Will check if our script does anything different from the nf-core version but this should be better for future plan. I'll try and do that commit before testing this

---

Note: the nf-core/bakta doesn't fix the pyhmmr version like in our modules/local/bakta/environment.yml.

• reproduce it and see if it works in the debug_mag_i86_i90 branch

dependencies:
  - bioconda::bakta=1.11.4 
  - bioconda::pyhmmer=0.11.4 #downgrading pyhmmer as mentioned https://github.com/oschwengers/bakta/issues/424

Difference from nf-core verion?

Our module is too long: overall, needs a careful check before replacement / break into other modules with nf-core

• Our version has some extra boilerplace to check for valid input fasta files and expected output files (these may not be necessary since nextflow takes care of these?)
• There is an extra visualization step using bakta_plot : this could be made into it's own module?

[microbemarsh]

Yeah please don't replace the bakta one, there is def some things custom with our module with the assembly subworkflow.