Rename arm profile

[edmundmiller]

https://github.com/nf-core/rnaseq/issues/1497

The addition of actual ARM processor support is causing confusing with the default arm profile.

The --platform=linux/amd64 is for Apple ARM-based computers emulating amd64 architecture. We really should rename that, and maybe it should be apple and arm correctly using the arm containers.

But I could see switch arm underneath being confusing.

So I'm proposing

1. Rename arm to apple
2. Create a new profile for arm based architectures like graviton. Name TBD but not arm to avoid gotchas when people are trying to run either.

Maybe arm64, graviton, linux-arm?

Background

• https://github.com/nf-core/tools/pull/2673
• https://github.com/nf-core/tools/pull/2034
• https://github.com/nf-core/tools/pull/1942#issuecomment-1320209648
• https://github.com/nf-core/tools/pull/1942

[mashehu]

I like linux-arm. Not a fan of graviton, because that's a product name. Arm64 is okay, but maybe not specific enough. We could then also rename the current one to apple-arm

[ewels]

1. Rename arm to docker_apple
2. Have docker_arm etc. from here

Not yet putting this into tools until ready

[pinin4fjords]

I like arm-apple, arm-linux. I'd rather not conflate with docker (I might want to specify conda differently as well for some edge cases), I want to say like --profile docker,arm-apple or --profile conda,arm-apple

[delagoya]

IMHO - A few items for consideration:

1. I would rather see the apple specific profile be names macOS (or mac_os if there is a snake case convention for profile names).
2. I would rather use aarch64 instead of arm64 since this is the official name for the 64-bit ARM architecture.
3. docker is vendor specific and maybe we should consider moving to container or oci as the nomenclature.
4. Similar issue with respect to apptainer vs singularity.
5. I would rather not conflate aarch64 with Docker since conda and Spack are packager options. container_arm or should stay as a separate profile for leveraging these containers build platforms but they should be separate from aarch64

[sateeshperi]

+1 for arm-apple, arm-linux

[pinin4fjords]

2. I would rather use aarch64 instead of arm64 since this is the official name for the 64-bit ARM architecture.

Agree with that actually

[pditommaso]

Not sure to understand the rationale to have "apple" mapping to amd64 platform, when Silicon corresponds to arm64?

[delagoya]

@pditommaso

Current arm64 profile that is created by nf-tools (and hence in most modules) only sets the docker runtime option to the use x86_64 container builds:

arm {
        docker.runOptions       = '-u $(id -u):$(id -g) --platform=linux/amd64'
    }

This was so Rosetta emulation can run the existing containers. Now that --platform=linux/arm64 is supported by both Seqera containers and Biocontainers, the profile name no longer makes sense. Renaming to either apple or mac_os makes it clear this is a "run an x86 container using Rosetta emulation"

[ewels]

Sorry, my comment was very brief as it was the end of a meeting and we were over time. Some additional detail:

Conflation with container tech

I think basically everyone would prefer to keep separate, however the reason for docker_arm instead of docker,arm is purely technical. Basically we will have a whole bunch of container URLs that are arm64 specific. Having combinatorial Nextflow config profiles to resolve these is messy. Having one config profile / file per combo is much easier.

It's this practical, rather than philosophical, reason that led me to this structure in the planning blog post, which I continue to suggest here today.

So to clarify, instead of docker,arm, conda,arm etc. I'm suggesting docker_arm, conda_arm etc (one per container tech) because this is easier to encode within Nextflow config. This doesn't preclude having apptainer_arm or any others, we can have *_arm for whatever tech we want.

If someone can think up some config syntax magic to do combinatorial profile includeConfig statements in a way that works nicely (eg. order that profiles are specified doesn't matter, for example), then happy to change on this. See what I sketched out already here - basically need an alternative to this for the nextflow.config example.

Apple / osx etc.

I also didn't love Apple, but @mashehu and @edmundmiller seemed to like it and I didn't care that much 😅 Conda uses osx/arm64. See for example samtools:

Other

I would prefer not to go for aarch64 even if it's official, as it seems to be less commonly used. At least, it's not used by Conda, Seqera Containers, docker hub and most others that I've come across.

[edit: it clearly is used by conda as shown in my screenshot directly above this comment 🤦🏻 - still, I prefer to avoid change unless there's a strong reason for it]

[awgymer]

Renaming to either apple or mac_os makes it clear this is a "run an x86 container using Rosetta emulation"

I disagree and I never liked the arm name for a profile that actually prevented arm containers being used even if they existed

It should always have had a name which made it clearer it was running x86 containers regardless of what was available so I similarly don't like e.g. apple-arm.

I would have thought apple-emulation, rosetta, amd-emulation, force-emualtion or some such is much clearer on the intent/use-case of the profile and less likely to have any future name clashes.

[delagoya]

@awgymer good point, I agree with "emulation" labels. @ewels as someone that spent a week of pain at the hackathon dealing with combinatorial profiles, I agree.

[ewels]

@awgymer - totally agree. This has been bugging me but I'd not been able to put it into words, but you hit the nail on the head there.

-profile emulate_amd64 maybe? Does what it says on the tin then!