Install script for CLI package

[krisbitney]

This PR adds an install script for the CLI package (standalone executable).

The script is adapted from https://github.com/teaxyz/setup/blob/main/install.sh. I gave credit at the top of the install script.

Usage instructions:

$ sh <(curl https://raw.githubusercontent.com/polywrap/cli/origin-dev/install.sh)

# Installs to `~/.polywrap`
# If polywrap is already installed, the script instead checks for updates

The script should work on MacOS, Linux, and WSL. I would appreciate if reviewers test it in their environments, especially if you have access to WSL. Native Windows support is not yet available for the installation script, so Windows users without WSL must download the executable and add it to their PATH manually.

This script cannot be properly tested until the next CLI GitHub release, which will include the first release of the standalone executables. I have tested the script using a test URL pointing to the NodeJS CLI binary and everything is working correclty in my environment (macos-arm64).

[cbrzn]

do we need these scripts or only the pkg:ci? can you explain to me what the pkg:ci does exactly? in my ignorance, it seems that is only building for one target but not sure

[krisbitney]

You're right, pkg:prod and pkg:dev are no longer used in CI/CD.

I think pkg:prod can be removed.

The pkg:dev script is useful if you want to test with the binary as you're working on the CLI, since it's fairly quick and it produces binaries for all of the targets. The tests will select the correct binary for your OS and arch. I think it's worth keeping.

[krisbitney]

The pkg:ci script only builds for the target used by CI. The purpose is to make CI faster. If we want fewer scripts, CI can just use pkg:dev.

[cbrzn]

The pkg:ci script only builds for the target used by CI. The purpose is to make CI faster. If we want fewer scripts, CI can just use pkg:dev.

right, so I think there's two things here (please correct me if I misunderstood something):

• Testing polywrap CLI as a standalone (in the CI), this will just build the binary in the gh action runner platform; and it will try to interact with the CLI; making sure it works as expected
• Doing the actual release; here the CD process is actually going to build the binaries to all supported platforms (which are defined here), and then just adding those as assets.

Based on this, what I would propose its to just have one script (I would actually name something like build:binaries), and then in the CI, we can do build:binaries -- -t node18..... This way we would just have one script that its reused in the different processes. Wdyt? @krisbitney

[krisbitney]

See #1892

[cbrzn]

this looks awesome :) thanks for pushing this. quick q: in order for me to test things locally we must do a release of the CLI; which will add the binaries into the release (as assets) and then I can just run the installation script locally; right?

[krisbitney]

this looks awesome :) thanks for pushing this. quick q: in order for me to test things locally we must do a release of the CLI; which will add the binaries into the release (as assets) and then I can just run the installation script locally; right?

yes, exactly

[dOrgJelli]

🔥