add gcta/gsmr tool

[juliaapolonio]

PR checklist

Closes #7975

• 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.
• Emit the versions.yml file.
• 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

[juliaapolonio]

Hi, I'm having linting issues with my code, in the meta.yml file. The error message is " The meta.yml of the module gcta/gsmr is not valid: {'reference': {'type': 'file', 'description': 'Reference files (BED, BIM, FAM) for GCTA analysis', 'pattern': '*.{bed,bim,fam}', multiple': True}} is not of type 'array'. Check the entry for input. "
I wasn't able to figure this out...

[d4straub]

Looks good, but args seem quite important to me.

[famosab]

Suggested change

	assert snapshot(
	process.out.gsmr,
	process.out.eff_plot,
	process.out.mono_badsnps,
	process.out.versions
	).match()
	assert path(process.out.versions.get(0)).text.contains("GSMR")
	assert snapshot(process.out).match()

That should work or is the md5sum of the log instable?

[juliaapolonio]

Yes the log is instable.

[famosab]

ok then still this line is not neceassry :)
assert path(process.out.versions.get(0)).text.contains("GSMR")

[famosab]

Is it expected that there is no eff_plot?

[juliaapolonio]

Yes, gsmr only emits the eff_plot when there are significant IVs which is not the case for this test data.

[famosab]

Suggested change

	path "${meta.id}_${meta2.id}.log" , emit: log
	path "${meta.id}_${meta2.id}.gsmr" , emit: gsmr
	path "${meta.id}_${meta2.id}.eff_plot.gz" , emit: eff_plot, optional: true
	path "${meta.id}_${meta2.id}.mono.badsnps", emit: mono_badsnps, optional: true
	path "*.log" , emit: log
	path "*.gsmr" , emit: gsmr
	path "*.eff_plot.gz" , emit: eff_plot, optional: true
	path "*.mono.badsnps", emit: mono_badsnps, optional: true

[famosab]

These need to be generic so that the pipeline dev can in therory change the prefix :)

[juliaapolonio]

That's true! But when I remove these {meta}, the lint fails with this message: 'meta' map not emitted in output channel(s)
Do you know a workaround for this?

[famosab]

Ah its because you do not emit the meta map :) the output needs to be structured as tuples:

tuple val(meta), path("*.log"), emit: log

and so on :)

[juliaapolonio]

Thanks for the help! I added this modification in my last commit

[famosab]

I think we allow only one meta map per output. Maybe you can ask in the slack for help for your specific use-case.