-
Notifications
You must be signed in to change notification settings - Fork 70
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
Make installing binary releases a native experience #1446
Comments
Of the options the most important of these to prioritise is probably |
Of the options that are low hanging fruit quick wins, that's |
I won't have access to a Windows machine until the end of August, but I can take a look after that. |
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. |
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 |
Need legal clearance |
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. |
|
Working on automation |
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:
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.[Edit: Deprioritizing for now.]curl -L https://cli.stellar.org | bash
)NPM, that installs the prebuilt binary (e.g.[Edit: Deprioritizing for now.]npm -g install @stellar/stellar-cli
)Cargo, that installs the prebuilt binary (e.g.[Edit: Deprioritizing for now.]cargo install stellar-cli-bin
)Docker (e.g.Add docker image #1550docker run -i stellar/stellar-cli
)Windows (x86)
winget install Stellar.StellarCLI
) @fnandomacOS (x86, arm64)
Linux (x86, arm64)
Debian/UbuntuSDF hosts an apt repo that could house the stellar-cli as a package to install.CI
- uses: stellar/[email protected]
@leighmccullochThe text was updated successfully, but these errors were encountered: