Create pydantic models for the different fusion callers

[jarbesfeld]

Feature description

The translators currently have a lot of arguments which can make them a bit unwieldy to use. We should create pydantic classes for these methods instead to make supplying data to these methods easier

Use case

Some of the translators have 10+ required arguments, which can make using these functions challenging.

Acceptance Criteria

New pydantic models are created for the different fusion callers, and the new models are imported and used as input in translators.py

Proposed solution

No response

Alternatives considered

No response

Implementation details

No response

Potential Impact

No response

Additional context

No response

Contribution

Yes, I can create a PR for this feature.

[jsstevenson]

Isn't this just displacing complexity behind another abstraction layer rather than reducing or streamlining it?

[jarbesfeld]

@jsstevenson Yes I would agree that the complexity remains the same. I wasn't sure if it was best practice to have the translator functions have so many parameters? For example, when adding support for the fusion metadata, the arriba caller has 19 parameters.

[jsstevenson]

It's not a bad idea, but I'd want to be thinking about ways in which the individual components can naturally be coupled in a way that reduces repetition or otherwise looks smoother. For example, if a function has args along the lines of (gene_1, gene_2, chrom_1, chrom_2, pos_1, pos_2) then maybe there's an object like a partner that has gene, chrom, and pos properties, so then the arguments are just (partner1, partner2).

Even better if there is some repetition across different callers so you can reuse some of those abstractions.

[jarbesfeld]

@jsstevenson I think that is a good idea. I can imagine creating one class to hold the genomic breakpoint data + transcript-specific metadata (i.e. Partner) and one class to hold all associated fusion metadata (i.e. FusionMetadata), where every parameter would be optional due to the absence of an intersection between the metadata output from the different callers.

The one issue is that some callers combine the genomic breakpoint data into one column (e.g. STAR-Fusion could output chr1:154170465:-​ while JAFFA would output the data in separate columns). This was the main reason why we do caller-specific processing of the data in each caller before we run the methods in fusor