I think this one @Famke Bäuerle reviewed could do with some more eyes from this group since it might be precedent-setting. I've spotted a few extra things https://github.com/nf-core/modules/pull/11053

yes it would be great if more people join, it was already wuite a bit of work to just get it to a sort-of-compliant state

Related question for the team. If module GPU enablement significantly increases container size, should we: 1. Use the same container across the board for ease of maintenance. Like this. 2. Switch out containers depending on GPU usage. More complex, but prevents bloat of the pipeline footprint. Like this. I'm coming across similar issues to the OP the PR here with Ribodetector, and we probably need a standard. My example: https://github.com/nf-core/modules/pull/11177. Ribodetector container is 3X the size with GPU pieces added.

I think 2, but a related question is how well the GPU versions of libraries work on a non-GPU system?

Let's assume for the same of argument that I'm talking about scenarios where the GPU container works identically to the CPU-only variant.

Generally I think, as developers of an open system of pipelines, we have a responsibility to minimise resource usage as much as possible - we never know what systems users will run these things on, but many users will not have access to large HPCs or cloud compute budgets, and are on systems where storage or memory is tight. Whether that be downloading smaller containers where possible, deleting large unused temporary files or clearing up directories full of inodes, we need to be mindful to make the pipelines as accessible as possible.

What sizes are we talking about? Because if 3x is still reasonably small I think its ok.

500Mb -> 1.5 Gb in this case

Ok haha then I am for 2️⃣

I added examples to the options above for what the syntax is like