Provide proper release artifacts

[Meijuh]

I think the approach of distributing aws sam cli needs serious reconsideration. My concern is largely based on this document https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html.
Distributions are responsible for distributing software, not the developer. AWS SAM CLI takes it to the extreme; an artifact that needs to be run as root in order to install. This makes it extremely and unnecessarily hard for third-party distributors. As a Fedora user, in order to update my system, not only do I need to update using DNF, I also need to update my python packages using PIP, and SAM itself using sudo ./sam-installation/install --update. This has all kinds of compatibility and security issues.

I kindly request you to work with maintainers on flexible and secure distribution of your software.

[hawflau]

Hey @Meijuh thanks for your suggestion. I'll bring it up with the Team.

That said, can you help me understand better about the installation experience in Fedora:

1. What did DNF and PIP update before you run sudo ./sam-installation/install --update?
2. Can you elaborate a bit more about what the compatibility and security issues?

As for the need of sudo, it's possible to specify an installation path (e.g. sudo ./sam-installation/install --install-dir $HOME/my/path). I wonder if sudo can be skipped if you install at a location where you have full access without sudo.

[Meijuh]

First, I needed to upgrade SAM/Python/PIP managed packages because whenever I ran sam deploy I got: "Error: An HTTP Client raised an unhandled exception: sequence item 0: expected str instance, bytes found" (the compatibility issue). So then I had to figure out/remember how and where sam was installed. This could be via pip/dnf/tarball, and apparently also now via a custom installer. So I just removed any form of sam. Upgraded all PIP packages via pip --disable-pip-version-check list --outdated --format=json | python -c "import json, sys; print('\n'.join([x['name'] for x in json.load(sys.stdin)]))" | xargs -n1 pip install -U, because that seems to be the way according to https://www.activestate.com/resources/quick-reads/how-to-update-all-python-packages/. But that also gave errors, because of missing dependencies. So I had to run dnf install librsync-devel libvirt-devel cairo-devel gobject-introspection-devel.

Then I ran the installer as root (I did not know about --install-dir), and hoped deeply it would not run rm / -rf (the security issue).

In three months I will have to do all steps above again, because I will have forgotten you made a custom installer.

Above steps could be optimized (I'm no python expert), but my point is, I would not have to think about it if only I could run dnf install aws-sam-cli. Also try to imagine if all software vendors took your approach (needing to know I can supply --install-dir to a custom installer, etc); upgrading my system would take days.

I would love to see the possibility you allow distribution maintainers to distribute your software in a way they recommend (and potentially assist them with that). That would make it so much easier for me to use the SAM CLI, and saves you work too of having to maintain an installer.

[hawflau]

Thanks for sharing your feedback and experience. It seems like you hit some unexpected cases. I'll mark this issue as bug and will investigate further.

In this issue, we explained why we decided to change our support model for homebrew, and also why we intented to keep a unified installation experience through our binary installers. Like homebrew, we welcome community to contribute and support distribution of AWS SAM CLI in different package managers(such as homebrew and pacman).

[Meijuh]

#5613 does not provide a single reason to drop support for homebrew? I'm honestly curious why the choice for a custom installer has been made.
You say you welcome the community to contribute, but you do not provide release tarballs aside from those automatically generated by Github.

At this point https://cloud.google.com/sdk/docs/install#red-hatfedoracentos looks like a godsend.

[jysheng123]

Hi Meijuh! We dropped homebrew for multiple reasons, mainly due to our decision of having a unified distribution, with homebrew having a different installation workflow than our own installers, since we are able to solely maintain and be responsible for our installers. unlike homebrew. Here is another ticket for more context.

That being said, thank you for taking the time to provide this feedback. I would like to better understand your use case. I tried replicating the installation/upgrade process using an EC2 Instance with AL 2023 and found my experience normal to the docs when installing/updating our package. I see that there are some issues with using DNF/pip/third part distros but that is to be expected with out current official installation method using our own distribution. Our team had a discussion and we believe it is best practice to use our own distribution in our case. Do you have a specific use case for special tarballs outside of the ones generated in our Github?

[mildaniel]

Closing due to inactivity.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.