Analysis API tied to workflow on instantiation
ChrOertlin opened this issue · comments
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.
Why would we not create a child class for each workflow? And then just not override anything?
I guess they way to go is to break the NfAnalysisAPI
into three separate classes for the specific workflows then?
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?)
Yeah, I guess it should not be necessary to provide the workflow if we have one child class per workflow already?
Refinement meeting
- revisit if any problems turn up