Can anyone remind me why we didn't just cram all 4+ container URIs into some squiggly brackets in the

process.container

directive? Instead of all the stuff with

meta.yml

and creating config files and stuff. I'm pretty sure we discussed it and I almost certainly advocated against it, I'm just struggling to remember why 🙈 😆

I think it makes the main.nf clearer

There is that, but it makes other stuff a lot less clear (multiple pipeline config files with container URIs, modules need meta.yml to be complete, a bunch of extra complexity in the automation)

For me, it's more whatever makes it easy for the end user first. So for me as a end user, I honestly don't care much about it. Then what is easier for the dev, and on that side, I think you already answered

For the pipeline / module dev it shouldn't matter much as everything should be automated pretty much

Yamls are a lot easier to parse than nextflow might also be a reason

For some context: I have a long thread with @pontus and was thinking that a dynamic container string could pick the correct container URI at run time based on

task.arch

and whether singularity / apptainer / docker is active.

I agree with what was already mentioned and can maybe add to it: • It makes the main.nf more readable • It is easy to parse = lint • Better linting + fixing = More frequent container updates? • It adapts easier to other architectures and engines we might want to add

Isn’t there a way of defining

task.ext

attributes from

<http://main.nf|main.nf>

directly ? To separate out defining the actual container paths from the logic of choosing the correct one for the OS / architecture. In Homebrew recipes, there’s a very clear section with all the package builds github.com/homebrew/homebrew-core/blob/…/lizard-analyzer.rb#… In Nextflow modules, that would be followed by a standard

container

line that has all the conditions etc, but only refers to the above variables. It’d be even better if Nextflow had 1st-class support for declining containers …

Yeah I have toyed with the idea of extending Nextflow to take either a string or a map for

container

. But new syntax immediately makes adoption tricky 🫠

Not sure I follow some of the reasoning above - if we have automation for this, linting essentially goes away?

Another point: we don't want people to manually edit them, so appending them to a meta.yml (we might even add a disclaimer comment in the future before the section), made more sense than in the middle of the

<http://main.nf|main.nf>