feat(runner.py): new function added: implemented a function to download and extract the exomiser runner

[souzadevinicius]

This function will handle the preinstallation processes for exomiser runner, and must exist for every different pheval runner ensuring a streamlined setup.

Impact: Enhances the installation workflow by automating the preparation of the Exomiser runner, improving efficiency and reducing manual steps

[yaseminbridges]

I like the concept but there are some issues with the code:

1. The code would benefit from being more modular, making it easier to maintain and for readability. For example, this could be wrapped up in a class separate from the runner class and then called within this install method. I would suggest this structure:

src/pheval_exomiser
├── __init__.py
├── cli.py
├── constants.py
├── install
│   ├── __init__.py
│   └── install_configurations.py
├── post_process
│   ├── __init__.py
│   ├── post_process.py
│   └── post_process_results_format.py
├── prepare
│   ├── __init__.py
│   ├── create_batch_commands.py
│   ├── tool_specific_configuration_options.py
│   ├── write_application_properties.py
│   └── yaml_to_family_phenopacket.py
├── run
│   ├── __init__.py
│   └── run.py
└── runner.py

and put all the code in the install_configurations.py and call in the runner.

2. Use docstrings in place of inline comments. Breaking the code up into smaller pieces as mentioned above will also remove the need for these comments.

I have one major question about this PR. How will this be implemented in the pipeline? Right now it is added as an install method in the runner - but this will not be called in the run process as it is not known by PhEval. I don't think we want to make this compulsory for all new runners as it increases the burden on new developers. If we add this to the abstract class and nothing is implemented in the concrete runner will this throw an error? I am just wondering if this would benefit from being a separate command - but this does add another step.

One last question - where will this be all installed? In the input directory?

[souzadevinicius]

I like the concept but there are some issues with the code:

1. The code would benefit from being more modular, making it easier to maintain and for readability. For example, this could be wrapped up in a class separate from the runner class and then called within this install method. I would suggest this structure:

src/pheval_exomiser
├── __init__.py
├── cli.py
├── constants.py
├── install
│   ├── __init__.py
│   └── install_configurations.py
├── post_process
│   ├── __init__.py
│   ├── post_process.py
│   └── post_process_results_format.py
├── prepare
│   ├── __init__.py
│   ├── create_batch_commands.py
│   ├── tool_specific_configuration_options.py
│   ├── write_application_properties.py
│   └── yaml_to_family_phenopacket.py
├── run
│   ├── __init__.py
│   └── run.py
└── runner.py

and put all the code in the install_configurations.py and call in the runner.

2. Use docstrings in place of inline comments. Breaking the code up into smaller pieces as mentioned above will also remove the need for these comments.

I have one major question about this PR. How will this be implemented in the pipeline? Right now it is added as an install method in the runner - but this will not be called in the run process as it is not known by PhEval. I don't think we want to make this compulsory for all new runners as it increases the burden on new developers. If we add this to the abstract class and nothing is implemented in the concrete runner will this throw an error? I am just wondering if this would benefit from being a separate command - but this does add another step.

One last question - where will this be all installed? In the input directory?

Hello, @yaseminbridges .

I agree 100% with your points. This PR is just a "concept"; we need to discuss the major details.
Answering your question about who will call it, we can have a pheval install method in the pipeline that looks at the pheval-config.yaml file and calls this method for every runner described in the configuration file.\nThe installation path has not yet been decided. We can define this together.