8000 Rename arm profile · Issue #3536 · nf-core/tools · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Rename arm profile #3536

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
edmundmiller opened this issue Apr 11, 2025 · 12 comments
Open

Rename arm profile #3536

edmundmiller opened this issue Apr 11, 2025 · 12 comments

Comments

@edmundmiller
Copy link
Contributor

nf-core/rnaseq#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
@edmundmiller edmundmiller mentioned this issue Apr 11, 2025
Closed
@mashehu
Copy link
Contributor
mashehu commented Apr 12, 2025

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

@mirpedrol mirpedrol mentioned this issue Apr 14, 2025
Open
@ewels
Copy link
Member
ewels commented Apr 22, 2025
  1. Rename arm to docker_apple
  2. Have docker_arm etc. from here

Not yet putting this into tools until ready

edmundmiller added a commit to nf-core/rnaseq that referenced this issue Apr 22, 2025
@edmundmiller
build(arm): Update profile names
3ca8c58 
nf-core/tools#3536
edmundmiller added a commit to nf-core/rnaseq that referenced this issue Apr 22, 2025
@edmundmiller
build(arm): Update profile names
91c65a2 
nf-core/tools#3536
@pinin4fjords
Copy link
Member
pinin4fjords commented Apr 22, 2025 •
edited
Loading

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
Copy link
delagoya commented Apr 22, 2025 •
edited
Loading

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
Copy link
Contributor

+1 for arm-apple, arm-linux

@pinin4fjords
Copy link
Member
  1. 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
Copy link

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

@delagoya
Copy link
delagoya commented Apr 22, 2025 •
edited
Loading

@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
Copy link
Member
ewels commented Apr 22, 2025 •
edited
Loading

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
Copy link
Contributor
awgymer commented Apr 23, 2025

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
Copy link
delagoya commented Apr 23, 2025 •
edited
Loading

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

@ewels
Copy link
Member
ewels commented Apr 23, 2025

@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!

@mashehu mashehu mentioned this issue Apr 24, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
arm64 software builds
Status: Backlog
nf-core infrastructure projects
Status: Todo
Milestone
No milestone
Development

No branches or pull requests
8 participants
@delagoya @ewels @pditommaso @pinin4fjords @mashehu @edmundmiller @awgymer @sateeshperi
0