Skip to content

New module : portello#11114

Open
sofiademmou wants to merge 6 commits intonf-core:masterfrom
sofiademmou:portello
Open

New module : portello#11114
sofiademmou wants to merge 6 commits intonf-core:masterfrom
sofiademmou:portello

Conversation

@sofiademmou
Copy link
Copy Markdown
Contributor

@sofiademmou sofiademmou commented Apr 2, 2026

PR checklist

Add new nf-core module Portello.

  • This comment contains a description of changes (with reason).
  • If you've fixed a bug or added code that should be tested, add tests!
  • If you've added a new tool - have you followed the module conventions in the contribution docs
  • If necessary, include test data in your PR.
  • Remove all TODO statements.
  • Broadcast software version numbers to topic: versions - See version_topics
  • Follow the naming conventions.
  • Follow the parameters requirements.
  • Follow the input/output options guidelines.
  • Add a resource label
  • Use BioConda and BioContainers if possible to fulfil software requirements.
  • Ensure that the test works with either Docker / Singularity. Conda CI tests can be quite flaky:
    • For modules:
      • nf-core modules test <MODULE> --profile docker
      • nf-core modules test <MODULE> --profile singularity
      • nf-core modules test <MODULE> --profile conda
    • For subworkflows:
      • nf-core subworkflows test <SUBWORKFLOW> --profile docker
      • nf-core subworkflows test <SUBWORKFLOW> --profile singularity
      • nf-core subworkflows test <SUBWORKFLOW> --profile conda

@sofiademmou sofiademmou changed the title Add new portello module New module : portello Apr 2, 2026
@sofiademmou sofiademmou marked this pull request as ready for review April 2, 2026 08:31
Copy link
Copy Markdown
Contributor

@famosab famosab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few things related to nf-test but looking good!

tag "samtools/index"
tag "find/concatenate"

setup {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a really large setup for a test. I think its fine but I would argue that one could generate the input file once and store it in test-datasets so that we do not compute it all the time :)

Copy link
Copy Markdown
Contributor Author

@sofiademmou sofiademmou Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you so much for your review !

I applied all your suggestions but I had a small question for this one (since I am pretty new to nextflow and nf-core I was not sure how to proceed) :
would it be better to generate and store only the assembly (result of HIFIASM) and keep the rest of the setup, so other people could use this file in other modules if needed ? Or should I generate and store the files I need for this module (results of MINIMAP2_ALIGN and PBMM2_ALIGN) even if it would only be used for this ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say it depends on the size, but my gut is usually that if you need many many setup steps that this is just a waste of compute. How big would these files be? I think we can justify storing them even if its just for the module. Did you check if there are no files that would fit your purpose?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see ! I would have to add 2 bam files and their index, the biggest file would be 54kb. I think that's reasonable, right ?
The setup for portello is pretty specific so I haven't found any files that I could use.

Comment on lines +11 to +12
tuple val(meta), path(asm_to_ref_bam), path(asm_to_ref_bai), path(read_to_asm_bam), path(read_to_asm_bai), path(ref_fasta), val(assembly_mode)
val output_vcf
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would put the val output_vcf also in the one input tuple :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok ! I'll add it so we have only one input tuple ! :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if you think that both the assembly mode and the output_vcf is not something you would decide on a per sample basis I think we can also put them into their own inputs. This whole input thing is something that I became a bit torn on what way would be the best way forward :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the assembly_mode should definitely be on a per sample basis, but I wasn't sure for the output_vcf. But I think it makes sense for it to be dependent on the sample, so I will leave it all in one input tuple as you suggested ! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants