Non existing BUSCO datasets selected by annotate.py

[mat43672]

Hello,

When providing a species name to "annotate", I end up with a choice of BUSCO datasets that do not exist.

My species is a Serinales (--species "Australozyma monospora"), so ascomycota_odb12 should be used, but I get serinales_odb12, which is not a BUSCO dataset.

There is a dictionary in config.py (busco_taxonomy); the key is the dataset to use, while the value contains all taxonomic nodes covered by the dataset to make the match.

These two entries in the dictionary are involved in this case.

Ascomycota is correct, as it is the first match in the lineage of my species, so both the key and the matching value would give a correct and most specific dataset.

"ascomycota": {
"superkingdom": "Eukaryota",
"kingdom": "Fungi",
"phylum": "Ascomycota",
},

The dictionary entry that is apparently being used, with two issues:

"debaryomycetaceae": {
"superkingdom": "Eukaryota",
"kingdom": "Fungi",
"phylum": "Ascomycota",
"class": "Pichiomycetes",
"order": "Serinales",
"family": "Debaryomycetaceae",
},

1. The matching value is returned, Serinales, but not the key (debaryomycetaceae).
2. The key would not be in the lineage of my species. It is indeed a Serinales, but not a Debaryomycetaceae.

I think the matching algorithm could still return the lowercase version of the match, but only the deepest level should be considered for the match, and in my case we would get Ascomycota from the "ascomcotya" entry.

In the meantime, I will manually define the BUSCO dataset to use with --busco-lineage.

[nextgenusfs]

What version of funannotate2 and buscolite were you using? Checking on whether this was due to recent change in supporting the new busco v12.2 models. I thought this was fixed in latest release.

[nextgenusfs]

Overview

A bug was reported by a user running annotate.py with species --species "Australozyma monospora". The user got serinales_odb12 as the selected BUSCO lineage, which does not exist.

Root Cause Analysis

1. Old Taxonomy Matcher Bug:
   Prior to commit b752659430a3e279b02179333522d5f59ab07431 (fixed in Oct 2025), best_taxonomy with exact=True had a bug where it would return the lowercase value of the matched level (e.g. "serinales" from "order": "Serinales") instead of the database dictionary key (e.g., "debaryomycetaceae"):

   # Old buggy code:
   return normalize(query[level])  # Returned "serinales" instead of "debaryomycetaceae"

   This has been resolved in newer releases starting from v26.6.9 and v26.6.21.

2. How Current Version Handles the Lineage:
   When queried, the JGI/NCBI taxonomy for Australozyma monospora returns:

   • order: Serinales
   • family: Metschnikowiaceae

   Under the current implementation of best_taxonomy(..., exact=True):

   • There is no exact match for family Metschnikowiaceae or order Serinales in the reference database.
   • It correctly falls back to a higher taxonomic category with an exact match, which is phylum Ascomycota.
   • As a result, it returns "ascomycota", downloading the valid ascomycota_odb12 dataset instead of crashing or downloading non-existent lineages.

3. TypeError Robustness Added:
   If the JGI taxonomy lookup fails (e.g. offline mode or rate limiting) and returns False, the code was previously passing False directly to choose_best_busco_species, raising a TypeError: argument of type 'bool' is not iterable. We have implemented graceful fallback handling inside best_taxonomy to return "eukaryota" or "fungi" if the input query is None or False.

Unit Tests Added

We added the following unit tests to test_utilities_taxonomy.py:

• test_australozyma_monospora: Verifies choose_best_busco_species correctly falls back to "ascomycota" for Australozyma monospora (Issue Non existing BUSCO datasets selected by annotate.py #91).
• test_none_taxonomy: Verifies None inputs fall back gracefully to "eukaryota".
• test_false_taxonomy: Verifies False inputs fall back gracefully to "eukaryota".

All tests passed successfully:

pixi run pytest tests/unit/test_utilities_taxonomy.py