-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: enabled mbcs meta-tool in the ngs_mapping step model #545
Conversation
The pull request CI testing is failing due to mamba configuration. It seems to use miniconda instead of miniforge, and it seems that the new conda solver matches mamba's performance(?). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thank you! :)
The only comments I have are rather general ones which we need to discuss for snappy in its entirety, i.e. are not specific to this PR.
@@ -28,6 +28,6 @@ class HlaTyping(SnappyStepModel, validators.ToolsMixin, validators.NgsMappingMix | |||
|
|||
tools: Annotated[list[Tool], EnumField(Tool, [Tool.optitype], min_length=1)] | |||
|
|||
optitype: Optitype | None = None | |||
optitype: Optitype = Optitype() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before I forget: This is a design decision we must make.
- Either we always provide all the defaults, and substeps are always registered irrespective of whether they're used or not, or
- we do not provide defaults but force
None
, in which case substeps must not be registered if the config doesn't provide the substeps and all functions in the workflow definitions (in the init.py files) must not access those non-existent config definitions (e.g. intget_output_files
etc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am tempted to always provide defaults. It makes the __init__.py
code easier, and I personally don't like to see:
step_config:
hla_typing:
tools: [optitype]
optitype: {}
For me, the syntax optitype: {}
suggests that the tool doesn't accept parameters, not that we use the defaults.
Also, I wouldn't always set all defaults for more complex steps/tools. If there isn't an obvious choice for a default, then the user should make a decision.
But again, I am prepared to be convinced otherwise.
if self.name not in self.config.tools: | ||
return {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also touches on the comment above
@@ -53,7 +53,7 @@ def pair_fastq_files(input_left, input_right): | |||
input_left = snakemake.params.args["input"]["reads_left"] | |||
input_right = snakemake.params.args["input"].get("reads_right", "") | |||
|
|||
config = snakemake.config["step_config"]["ngs_mapping"]["somatic"] | |||
config = snakemake.config["step_config"]["ngs_mapping"]["mbcs"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for now, we can do it like this, and then later move those config accesses to the parameters
Quick & dirty fix.
TODO: check & fix the whole pipeline (#528 )