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:
This is the preprocess.smk module that is currently implemented in Cyotsnake. Currently, the rules aggregate, annoate, and normalize 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 within preprocess.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 whole preprocess.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:
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.
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