Do we have a plan for modules that contain Dockerf...
# team-maintainers
e
Do we have a plan for modules that contain Dockerfiles?
Copy code
22 Dockerfiles found.
- antismash
- bcl2fastq
- bclconvert
- cellranger (Dockerfile.manual)
- cellranger/mkfastq (Dockerfile.manual)
- cellrangerarc
- cellrangerarc/mkfastq
- cellrangeratac
- cellrangeratac/mkfastq
- coreograph
- force/cube
- force/tileextent
- mat2json
- numorph/3dunet
- numorph/intensity
- numorph/resample
- snpeff
- spaceranger
- universc
- vizgenpostprocessing
- wittyer
- xeniumranger

Some of these Dockerfiles sit in a tool folder that holds subcommand modules, not in a single module's folder. For example, antismash/Dockerfile and cellranger/Dockerfile.manual belong to the whole tool folder.
Do we plan to migrate those with wave (via the new nf-core containers command) and remove the Dockerfiles? @Maxime Garcia has a couple of those and was OK with me removing Dockerfiles and updating containers. Are there some that wouldn't get working containers simply through wave, and would still require their Dockerfile? Let me know, and I will open an issue to track these down. Would also be linked to this issue: github.com/nf-core/modules/issues/7781 regarding linting failing for these modules. And probably to the renovate dashboard one? github.com/nf-core/modules/issues/4211
j
Some have political contexts too which may not be described there.... So it might have to be a case by case basis
m
Snpeff can be removed
🫡 1
p
As noted recently, the cellranger ones can't be done anything about, same seems to be the case for spaceranger, xeniumranger (10x commercial), universc ("special", recently redone with 10x dependency?), bcl2fastq, bclconvert (Illumina commercial), wittyer (says Illumina commercial, but seems unclear?) Some other may have weird ways that make me uncomfortable without being able to pinpoint exactly why (e.g. mat2json which builds on matlab runtime images which generally lists as "free to download", has no license agreement I can easily find and requires approval of that for use (but that can be done by an ENV in a Dockerfile, whatever that means for end users and so on). End result: as suggested by James, I think one should walk through the list and and one will be able to remove a few (and that's good), but the majority will remain snowflakes (and those might be good to flag/track somehow if that's not already done, both for making this kind of thing easier but especially assuming fifteen years of core teams rotations and some asset being sold off to companies that buy stuff that's not commercially viable and litigate what they can, for such cases one would want have the agreement with 10x that says nf-core may distribute xeniumranger documented somewhere findable).
party this 1
👍 2
e
Can still make the issue on GitHub to track and flag accordingly I guess
👍 1
Will make a table, thanks 😄
s
Yeah, many of them are not available on biocontainer for specific reasons
e
Made the issue to track the progress of nf-core modules that have a Dockerfile in their subfolder: github.com/nf-core/modules/issues/13412 Should probably need to make a lint exception for the ones that NEED to stay with a Dockerfile
👍 1
p
Great job!