Skip to content
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.

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

Make installing binary releases a native experience #1446

Open
3 of 9 tasks
leighmcculloch opened this issue Jul 12, 2024 · 10 comments · Fixed by stellar/homebrew-tap#44 or Homebrew/homebrew-core#180191
Open
3 of 9 tasks
Assignees

Comments

@leighmcculloch
Copy link
Member

leighmcculloch commented Jul 12, 2024

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

  • curl | bash (e.g. curl -L https://cli.stellar.org | bash) [Edit: Deprioritizing for now.]
  • NPM, that installs the prebuilt binary (e.g. npm -g install @stellar/stellar-cli) [Edit: Deprioritizing for now.]
  • Cargo, that installs the prebuilt binary (e.g. cargo install stellar-cli-bin) [Edit: Deprioritizing for now.]
  • Docker (e.g. docker run -i stellar/stellar-cli) Add docker image #1550

Windows (x86)

  • Winget (e.g. winget install Stellar.StellarCLI) @fnando

macOS (x86, arm64)

Linux (x86, arm64)

CI

@github-project-automation github-project-automation bot moved this to Backlog in DevX Jul 12, 2024
@leighmcculloch leighmcculloch changed the title Distribute binary releases to at least one package manager per platform Make installing binary releases a native experience Jul 12, 2024
@leighmcculloch
Copy link
Member Author

leighmcculloch commented Jul 12, 2024

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
Copy link
Member Author

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

fnando commented Jul 12, 2024

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

@leighmcculloch
Copy link
Member Author

@leighmcculloch
Copy link
Member Author

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

Ifropc commented Oct 18, 2024

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

Need legal clearance

@janewang
Copy link
Contributor

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

fnando commented Nov 14, 2024

@janewang
Copy link
Contributor

Working on automation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
4 participants