Decoupling rule modules into individual components #33
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
About this PR
This PR focuses on separating and
rules
into individual components. In the current version, there are some rules modules that contains multiple rules that conduct different process:preocessing.smk
This is the
preprocess.smk
module that is currently implemented inCyotsnake
. Currently, the rulesaggregate
,annoate
, andnormalize
are strongly linked because each rule expects outputs from the previous rules.Creating a strong cohesion between rules will require developers to repeat the same code in their modules.
For example, since the
normalize
rule is deeply coupled withinpreprocess.smk
, then the user will have to create another rule module that will contain the normalization process.In addition, this makes rule modules non-extensible to major workflows. If you’re designing a major workflow and you require the
normalization
, then it will require the wholepreprocess.smk
to be imported to your workflow, which is not ideal, hence decoupling is a great solution to this problem.Separating modules into individual components
Separating each rule into it’s own independent modules has it’s advantages. It will remove repeated code and increase extensibility.
Therefore it will look like this (decoupling
preprocess.smk
:aggregate.smk
annotate.smk
normalize.smk
Now each components is individually, developers can import these modules to their workflows without any problem!
Another additional feature this PR introduces is the ability to inherit modules. Here’s an example: Let’s say we’re creating a new module but we also want this new module to create a tight couple with the normalization method.
This can be easily solved by inheriting the
normalizatio.smk
into your new rule module.new_rule.smk
the
include
is similar to python’simport
call, as it imports the namespace into thenew_rule.smk
This is beneficial because users do not have to write a new module or repeat code within the
new_rule.smk