A new request to upload a container to quay.io has been made! • Container URL: https://quay.io/repository/amihajlovski/immunebuilder • Why is this needed?: For a soon-to-be-added abodybuilder2 module and potentially future nanobodybuilder and tcrbuilder2 modules • Confirmation: ◦ This can't be done through the usual Bioconda Note: only containers with a stable version will be accepted (ie. not

latest

) Core team will add this container to quay.io. Please react to the message with ✅ when this is done. [This process is not automated] submitter: @Adrian Mihajlovski

I can't access the container for now

Should be fixed now

do you have a Dockerfile for this?

Here's the current Dockerfile for reference https://github.com/JelPej/nf-core-antibody-pipeline/blob/abodybuilder2-module/modules/nf-core/abodybuilder2/Dockerfile

ok, so from what I can see it's pip and conda install

Yes, it's also caching the model weights so they aren't installed every time

Yeah, I'm wondering if we can be smarter here or not

Yeahhhh, I general feel you shouldn't couple data with software itself

What should we do instead? The library does allow specifying a path for the weights

Yeah eaxaclty: yu have the module have a second input channel which is where you supply the path to the 'data' (in this case the weights)

I agree with you @James Fellows Yates

Alright, I suppose we can just use Seqera for this container then

In such a case, you could make a seqera containers for this

I'm thinking about whether we need a standard nf-core approach for dealing with model weights (and containers) since this comes up a lot in different modules. It's kind of like the situation with reference genomes but not quite the same. Is anyone working on that?

I think here is fine for now: can you describe what the difference is with reference genomes?

The data file (or files) is specific to each tool/module, where the reference genome is broadly usable by many tools. I don't think there would be the same economy of scale for model weights because of that.

We have a lot of a similar things in metagenomics where we have have tool specific databases, that can be really big (>110gb in some cases). Even then we recommend splitting these off away from the tool itself. Having to repeatedly pull massive containers really sucks. It's much faster to put the data in an shared cache location on a FS or with S3 where the transfer is more speedy - also because nextflow only had to stage it once and link from there