WIP: Discussion about input parameters

[ewels]

Result of discussion at the nf-core core team retreat.

[edmundmiller]

Think using those as yamls is the move. Then we can do a "on-changes" CI to launch tower jobs.

Ooo better, yet, we can cat the yamls together if they've changed and launch one tower job PR commit instead of multiple.

I was hating on the - genome: ... part, but that's going to come in really handy.

[maxulysse]

I like where this is going

[adamrtalbot]

One problem I have with the current genomes is the static nature. There isn't one version of GRCh38, there is a 1-to-many relationship between the genome build and annotation data (here, a GTF file). Can we include that somehow? 🤔

[adamrtalbot]

See Sarek with it's various GRCh37/38 builds: https://github.com/nf-core/sarek/blob/6aeac929c924ba382baa42a0fe969b4e0e753ca9/conf/igenomes.config#L14

[edmundmiller]

That's fine, these are just some initial examples.

I don't think the bottleneck isn't going to be:

1. Storage space
2. Compute

It's going to be:

1. Collaboration overhead
2. Getting things right and keeping it simple (The Sarek example is perfect)
3. Egress fees

[adamrtalbot]

These need to at least be maps or something to capture versions, different builds etc. For example, if we add MANE (the most appropriate transcriptome build for most people):

Suggested change

	- ensembl
	- ucsc
	- ncbi
	- gencode
	- refseq
	- encode
	- custom
	- ensembl
	- ucsc
	- ncbi
	- gencode
	- refseq
	- encode
	- MANE
	- refseq
	- ensembl
	- custom

[adamrtalbot]

Suggested change

	properties:
	# Required
	reference_id:
	properties:
	version: 0 # version of this document!
	# Required
	reference_id:

[adamrtalbot]

Surely you mean?

Suggested change

	type: string
	type: file

[edmundmiller]

Don't look at me, @ewels 😆

[edmundmiller]

I'm gonna go ahead with this one and merge it, and we can follow up with those in another PR.

I feel like there's a better/prettier way to do the yaml, but I can't seem to get it to work with nf-validation.