Analysis API tied to workflow on instantiation

[ChristianOertlin]

Description

Currently the analysisAPI requires a workflow to be passed for its instantiontion:

class AnalysisAPI(MetaAPI):
    """
    Parent class containing all methods that are either shared or overridden by other workflow APIs.
    """

    def __init__(self, workflow: Workflow, config: CGConfig):
        super().__init__(config=config)
        self.workflow = workflow
        self._process = None

We should likely refactor this so that it becomes workflow agnostic as we currently run into requiring work arounds when using the NFAnalysisAPI (a child of the AnalysisAPI) as this also requires a workflow parameter for instantiation. However, the NFanalysisAPI is common for three separate workflows and therefore the old way for the analysis api breaks.

@click.command("nf-workflow-past-run-dirs")
@click.argument("workflow", type=click.Choice(Workflow), help="Specify workflow to clean up.")
@OPTION_YES
@OPTION_DRY
@ARGUMENT_BEFORE_STR
@click.pass_obj
def nf_workflow_past_run_dirs(
    context: CGConfig,
    before_str: str,
    workflow: Workflow,
    yes: bool = False,
    dry_run: bool = False,
):
    """Clean up of "old" nextflow case run dirs."""

    analysis_api = NfAnalysisAPI(config=context, workflow=workflow)
    exit_code: int = EXIT_SUCCESS

    try:
        analysis_api.clean_past_run_dirs(yes=yes, dry_run=dry_run, before_str=before_str)
    except Exception as error:
        LOG.error(repr(error))
        exit_code: int = EXIT_FAIL
    if exit_code:
        raise click.Abort()

Suggested solution

Write here if there is a suggested way to solve the issue

This can be closed when

Describe what needs to be done for this issue to be closed

Blocked by

If there are any blocking issues/prs/things in this or other repos. Please link to them.

[Isak Ohlsson Ångnell]

Why would we not create a child class for each workflow? And then just not override anything?

[Sebastian Allard]

I guess they way to go is to break the NfAnalysisAPI into three separate classes for the specific workflows then?

[Sebastian Diaz]

a first thought: Would it work to define a self.workflow in the __init__ method of each child class with the corresponding workflow (a constant I suppose)? then all methods would have a self.workflow attribute but the parent class would remain agnostic to it as it would be an abstract attribute (is that a thing?)

[Isak Ohlsson Ångnell]

Yeah, I guess it should not be necessary to provide the workflow if we have one child class per workflow already?

[ChristianOertlin]

Refinement meeting

• revisit if any problems turn up