Conversation
…s and starting a list of optional parameters
|
|
||
| script: | ||
| def args = task.ext.args ?: '' | ||
| def prefix = task.ext.prefix ?: "${meta.id}" |
There was a problem hiding this comment.
If I understand the comment in line 33, This will ensure that files are named with an appropriate default prefix, but it can be overridden:
| def prefix = task.ext.prefix ?: "${meta.id}" | |
| def prefix = task.ext.prefix ?: "${meta.id}_prep" |
| // NOTES - post seems to need only the BAM *names*, not the actual files. Could we just get the first line of each file to get the names? | ||
| // for file in `ls multi_bam_rmats_prep_tmp/*.rmats`; do head -1 $file; done | tr '\n' ',' | ||
| // NOTES - for stats, it should be possible to parse the formula using patsy, but if we include PAIRADISE we might have R - just do this in R, first pass | ||
| path reference_gtf |
There was a problem hiding this comment.
Do you mean it should be
tuple val(meta), path(reference_gtf)?
Also, should rmats_read_len have a meta? (one line below)
There was a problem hiding this comment.
meta2, but yes.
I wouldn't put a meta on the value channel.
| params.novel_splice_site ? "--novelSS" : "", | ||
| (params.novel_splice_site && params.minimum_intron_length) ? "--mil ${params.minimum_intron_length}" : "", | ||
| (params.novel_splice_site && params.max_exon_length) ? "--mel ${params.max_exon_length}" : "", |
There was a problem hiding this comment.
Don't think we should be using params here?
There was a problem hiding this comment.
But the documentation states that optional parmeters should be given via ext.args, and the example shows it with params
https://nf-co.re/docs/guidelines/components/modules#optional-command-arguments
How else can I put these optional params?
There was a problem hiding this comment.
But this is a config for the nf-test, not for the module itself.
There was a problem hiding this comment.
So params.novel_splice_site is not defined at all, and even if you put the module into a pipeline this config won't get used at all anyway, because it is just for nf-test.
There was a problem hiding this comment.
There was a long discussion on Slack with @jfy133 about the usage of config files and parameters, right https://nfcore.slack.com/archives/C043FMKUNLB/p1768941551558009 and I thought I was doing what was discussed there.
I plan to have a modules.config for the rmats sub-workflow, which will have one file, but 4 config sections (one for each module). Currently, I added a module.config for this test, just to check that eveything behaves as it should for this task.
@jfy133 - could you please clarify this question for me?
| // NOTES - post seems to need only the BAM *names*, not the actual files. Could we just get the first line of each file to get the names? | ||
| // for file in `ls multi_bam_rmats_prep_tmp/*.rmats`; do head -1 $file; done | tr '\n' ',' |
There was a problem hiding this comment.
If you only need the bam names, then you could pass along the ${prefix}.prep.b1.txt file as an output of this module potentially.
There was a problem hiding this comment.
Good suggestion, thank you.
I'm going to need to see how rmats post behaves to figure out the best way, but I'll keep it in mind.
3 participants
PR checklist
This is a PR of rmats/prep.
RMATS processes BAM files from RNAseq and identifies splice junctions used, and differences between groups of samples.
RMATS is composed of 4 stages (that can be run together), but I'm planning to split into steps
I will then set up a workflow that does all 4.
Eventually, the workflow will close #8699 . Please do not close the issue yet.
This creates the main.nf for rmats.py prep command, and adds tests for multiple parameters that can be given to rmats prep.
topic: versions- See version_topicslabelnf-core modules test <MODULE> --profile dockernf-core modules test <MODULE> --profile singularitynf-core modules test <MODULE> --profile conda