aws / aws-cli

Universal Command Line Interface for Amazon Web Services
Other
15.52k stars 4.12k forks source link

No official way to install the AWS CLI (v2) on Mac M1 (without Rosetta) #7252

Open maishsk opened 2 years ago

maishsk commented 2 years ago

Describe the bug

There is no package available for M1 Macs for the AWS CLI v2.

The only current way to do so is through Homebrew

the problems are detailed here - https://roadtoaws.com/2022/02/10/installing-aws-cli-on-apple-silicon/

Expected Behavior

Base don the documentation I would assume that I can do this

curl "https://awscli.amazonaws.com/AWSCLIV2-arm64.pkg" -o "AWSCLIV2-arm64.pkg"
sudo installer -pkg AWSCLIV2-arm64.pkg -target /

Current Behavior

The only way to install AWS is through Homebrew.

This is an unofficial workaround https://roadtoaws.com/2022/02/10/installing-aws-cli-on-apple-silicon/

Reproduction Steps

https://roadtoaws.com/2022/02/10/installing-aws-cli-on-apple-silicon/

Possible Solution

https://roadtoaws.com/2022/02/10/installing-aws-cli-on-apple-silicon/

or to install Rosetta on a M1 Mac https://support.apple.com/en-il/HT211861

Additional Information/Context

No response

CLI version used

v2

Environment details (OS name and version, etc.)

M1 Mac

mahi072 commented 2 years ago

Hi @maishsk, I would like to contribute in this issue, if its still open. Please guide me through this.

tim-finnigan commented 2 years ago

Hi @mahi072 thanks for reaching out. We had a related issue recently that I'll link here: https://github.com/aws/aws-cli/issues/6689. There is also a tracking issue for installing the CLI v2 from source: https://github.com/aws/aws-cli/issues/6785, and once that ability is fully implemented then it could be an official way to install v2 on M1 Macs without requiring Rosetta. But for now we can consider this a separate feature request to support installation on M1 Macs without requiring Rosetta. Others can 👍 this issue if they are also interested in this.

BradleyYeo commented 2 years ago

you can do it via homebrew: https://formulae.brew.sh/formula/awscli

mahi072 commented 2 years ago

Sure, I'll have a look on these and come back to you.

rafrafek commented 2 years ago

I installed Rosetta because of this and I don't know how to uninstall Rosetta 😢

Edit: I removed Rosetta using Recovery mode and then installed AWS CLI v2 using Brew and now it works natively 😎

BrianGallew commented 1 year ago

This would be trivially solved if the relevant python packages were uploaded to pypi. The lack of OS-specific packages (rpm, deb, etc) is also a problem in the face of a restricted environment like GovCloud where everything is supposed to be easily audited.

l1x commented 1 year ago

As of 2023.06.15 there is still no ARM64 AWS CLI v2.

QuinnyPig commented 1 year ago

The state and longevity of this issue are frankly absurd.

rodrigodiasf1984 commented 1 year ago

Any update on this?

image image

I`ve already tried to install it with brew, curl, npm and yarn without success.

tim-finnigan commented 1 year ago

Thanks all for the feedback. I just updated the issue title to clarify that installing v2 on Mac is supported as documented here, but this issue specifically relates to M1 Macs without Rosetta installed.

I also want to let everyone know that the ability to build and install v2 from source is now available: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-source-install.html. That can provide a workaround for folks and we can continue tracking the request to support an installer for M1 here.

asesh commented 1 year ago

Any ETA on when it will natively support Apple Silicon? The developers have had enough time to port their code to Apple Silicon but a project like this with millions of users didn't even bother to do so @tim-finnigan

nkadel commented 1 year ago

I've looked at this myself. Publishing AWSCLI v2 only via github.com tags, and not publishing it at pypi.org, will make standard "pip install" very difficult indeed, and interfere with other software bundling tools like apt or RPM. It's not clear why you've elected to do such a major revision, referred to as "awscli2" in various places, without actually publishing it as a distinct tool with distinct python modules.

The dependency chain of python modules for RHEL and Fedora are pretty long and have conflicting dependencies for related modules like "pluggy". I don't see that it will ever be reasonable to port and package aws-cli version 2.x to Amazon Linux 2 with all these dependencies.

jsermeno commented 11 months ago

@tim-finnigan The automated installation instructions at the link you provided still require Rosetta to install on an M3 Max chip. Is this a regression?

Installing from source still works.

asesh commented 10 months ago

Thanks all for the feedback. I just updated the issue title to clarify that installing v2 on Mac is supported as documented here, but this issue specifically relates to M1 Macs without Rosetta installed.

I also want to let everyone know that the ability to build and install v2 from source is now available: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-source-install.html. That can provide a workaround for folks and we can continue tracking the request to support an installer for M1 here.

@tim-finnigan Isn't it time to drop support for Rosetta completely and natively support Apple Silicon? If the source can be compiled and run w/o Rosetta, why can't you guys update the installer? It's been so many years, really?

dolmen commented 10 months ago

The issue is that the official package distributed at https://awscli.amazonaws.com/AWSCLIV2.pkg still installs x86 binaries instead of universal binaries or arm64 binaries.

$ arch
arm64
$ file /usr/local/bin/aws
/usr/local/bin/aws: Mach-O 64-bit executable x86_64

Like many developers on macOS, the AWS CLI is the only pure x86_64 binary remaining on my machine.

What is so special about that binary that the program can't be rebuilt (and distributed) as a native arm64 binary?

dolmen commented 9 months ago

This ticket is still labelled feature-request. In 2024, this should be marked as a bug.

iahsanm commented 8 months ago

Still facing the same issue on M2, going to install with homebrew.

asesh commented 8 months ago

The issue is that the official package distributed at https://awscli.amazonaws.com/AWSCLIV2.pkg still installs x86 binaries instead of universal binaries or arm64 binaries.

$ arch
arm64
$ file /usr/local/bin/aws
/usr/local/bin/aws: Mach-O 64-bit executable x86_64

Like many developers on macOS, the AWS CLI is the only pure x86_64 binary remaining on my machine.

What is so special about that binary that the program can't be rebuilt (and distributed) as a native arm64 binary?

Either they are too lazy or they are just ignoring it. It's 2024, almost all the apps that I use are native to Apple silicon.

dolmen commented 6 months ago

In the context of the xz backdoor, I'm questionning the (lack of) AWS answer to this ticket:

wnykuang commented 6 months ago

What's the difference between the one from brew and the official one? Looks like the brew one comes with same version number.

shaul75 commented 5 months ago

This ticket is still labelled feature-request. In 2024, this should be marked as a bug.

+1

Seriously why is it so long to release a native ARM version? isn't it as simple as to compile the existing code, sign and release it? I don't want to use brew nor run it in rosetta. There are no more apple devices with intel CPUs being produced, if AWS keeps support for MacOS at all this is long overdue

magnetikonline commented 5 months ago

I don't want to use brew nor run it in rosetta.

I felt the same way. I just reinstalled macOS Sonoma and thought I could finally avoid Rosetta in 2024 - I found this really surprising.

Luckily installing from source is a pretty painless process - put together a simple script to perform the process and to re-run it as needed to upgrade: https://gist.github.com/magnetikonline/cf40e813b7bb87e94df955d0c80cd310.

SushantMongia commented 3 months ago

if you install from brew brew install awscli and check for version you should get the following:

aws --version
aws-cli/2.17.9 Python/3.11.9 Darwin/23.5.0 source/arm64

unable to check for botocore version, unless it doesn't apply to M2 somehow..

In the context of the xz backdoor, I'm questionning the (lack of) AWS answer to this ticket:

  • is the AWS CLI frozen due to customers requests ("do not change it because it has gone through deep security audit and a new release would require to do the audit again", but are those audits results publicly available?)
  • is the AWS CLI frozen to preserve the undisclosed bugs/features that the binary contains?

@dolmen raised a very good point, adding context for those who read that comment, i was lost for a second. You can find more info from AWS regarding the xz package issues on their security bulletin for CVE-2024-3094 here, it affects version 5.6.x

And if you do end up wanting to install /installing nonetheless using brew and wonder if it's okay, well brew does install the older version of the xz package and its being intentionally kept that way and you can read more on the Homebrew discussions here, so that's that.

==> Installing awscli dependency: xz
==> Downloading https://ghcr.io/v2/homebrew/core/xz/manifests/5.4.6

Anyway still, waiting for official updates from AWS.

nkadel commented 3 months ago

The AWS CLI v2 bundlinig is still nasty for RHEL and Fedora as well as for the freshly published CentOS 10. The very large python module dependency chain creates a real stability and compatibility burden. It can work in a "docker" or other highly restricted environment, but if other python based tools need to integrate cleanly with it, it becomes very difficult. I currently count a dependency of roughly 90 modules, not part of the basic system python release, to satisfy the dependencies for AWSCLI v2.

jtele2 commented 1 week ago

What's the update on this? Also, I installed with Rosetta (why not) but now I can't figure out how to actually run the cli!?

nkadel commented 1 week ago

The code is so divergent, and so dependent on a vastly different stack of modules, that it should be published as a distinct github repo and distinct pypi.org module.