search

stellar / stellar-cli

CLI for Stellar developers
Apache License 2.0
74 stars 72 forks source link

Make installing binary releases a native experience #1446

Open leighmcculloch opened 4 months ago

leighmcculloch commented 4 months ago

Installing the CLI from source is the primary way we advertise installing the CLI.

However, building from source is time consuming and makes some assumptions about environment setup, additional compilers like a C compiler, and uses non-trivial amounts of memory resources, bandwidth, CPU capabilities, and ... patience.

We also prebuild binaries for Windows (x86), macOS (x86, arm64), and Linux (x86, arm64). Theoretically no one needs to build from source except those on esoteric systems. In terms of commands on the command line installing from source is the simplest, and so I think it is highly unlikely that folks use the prebuilt binaries much, especially given than our CI job for publishing the binaries is partly broken and requires manual running after each release and even on times we've forgotten no one has complained.

We should make these binaries easy to install using tools folks already have on their system.

While we do support cargo-bininstall, that binary is not often installed for folks and itself is a reasonably large installation. It's a good option to have on hand for folks who have it, but shouldn't be the core of the distribution story.

I think we should make a one line shell script install that works for the majority of users:

curl -L https://cli.stellar.org | bash

And similar for Windows if such a command exists, or winget is probably more appropriate given it is built-in to Windows.

I think we should also add release targets for all of the following, over time. For any platform where multiple options are listed, I've ordered them by priority.

Crossplatform

Windows (x86)

macOS (x86, arm64)

Linux (x86, arm64)

CI

leighmcculloch commented 4 months ago

Of the options the most important of these to prioritise is probably winget, because it seems like of folks who have issues building and installing the CLI, windows users are most represented. I'd happily take it, but I don't have access to windows and it'd be good if a native windows user could explore it. (cc @fnando Not sure if that's something you could do with your windows machine. I assigned you, but feel free to unassign yourself.)

leighmcculloch commented 4 months ago

Of the options that are low hanging fruit quick wins, that's homebrew binaries, because we already have a homebrew-tap and it's a short step to add binaries 🤞🏻. I'm going to take doing that because I'm familiar with homebrew.

fnando commented 4 months ago

I won't have access to a Windows machine until the end of August, but I can take a look after that.

leighmcculloch commented 3 months ago
leighmcculloch commented 1 month ago

I striked the apt deb because I realised no one has asked for this, and recently we used homebrew in a docker image where we might have otherwise used the deb and it worked fine.

I striked the docker image for similar reasons, to pare this back for higher impact and reduced maintenance on lower impact things.

Ifropc commented 1 month ago

I agree that publishing in apt is low impact + not everyone (I think not even 50% of desktop users) is using apt + people should be more comfortable installing it using cargo

janewang commented 3 weeks ago

Need legal clearance

janewang commented 3 weeks ago

Based on emails from legal, there's no need to disclose any 3rd party contributions in s3 as all contribution is original. This issue is not blocked on the legal front.

fnando commented 1 week ago
janewang commented 6 days ago

Working on automation