Improve parsing of GenBank / GFF files #1351

This follows my own advice in <#953 (comment)> and sets the stage for subsequent commits to improve the code. There are no functional changes here.

Both functions which call this would check for a return value of None (indicating that the file didn't exist) and cause the augur function to exit. It's cleaner to lift this into `load_features` and this makes it easier for that function to raise errors in the future (e.g. on malformed/empty reference files).

Also catches the edge case where a GFF has no valid rows. The printed error messages should be helpful enough to identify the GFF formatting error(s).

See comment added in code which details the previous behaviour. While silently skipping genes without the necessary attributes isn't the best solution in my opinion, it's at least now consistent (and also consistent with how we handle GenBank parsing). Closes #1349

This fixes a long-standing oversight in Augur where GFF files could only define the nucleotide coordinates via a row with GFF type 'source'. We now parse the (preferred) GFF type 'region' as well as the '##sequence-region pragma'. This allows us to exit if the nuc coordinates are not defined, and the error message should help users correct their GFF files. Note that the code is not yet implemented which guarantees the extracted nuc coordinates will be exported in the JSON. The changes here resulted in a number of tests needing updated, largely due to us now parsing an additional feature from GFF files (the 'nuc' feature)

A companion commit to the previous one, this time using GenBank files.

This name is reserved in our annotations schema to refer to the genome / segment / sequence nucleotide annotation.

This builds off the preceding 3 commits which guarantee that a 'nuc' feature will be parsed from the reference file. We now guarantee it'll be exported in the node-data JSON. Note that the change to the TB aa_muts.json test file was due to a bug in the previous code, where `'type: feat['type']` would incorrectly reuse the last defined `feat` in the preceding loop. (I think this is a pitfall of using large "real-life" test files as it's impractical to manually check the source-of-truth we are comparing against.) Since the 'nuc' feature is guaranteed to exist, we can also check it against the existing nuc annotation within `augur ancestral`, where applicable. Closes #953, although there is good commentary in that issue about improving our parsing of GFFs more generally than that implemented here. Closes #1346

These were previously either silently skipped or, in some cases an unhandled exception was raised.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve parsing of GenBank / GFF files #1351

Improve parsing of GenBank / GFF files #1351

Commits on Dec 20, 2023