document/bless installer args, and make sure they're consistent
Although our installers are largely designed to just be run without any user input, they do support several useful inputs.
We've never guaranteed/documented these arguments, as they largely fall into 2 major buckets:
- protocol between the installer and axoupdater
- something used for internal testing/debugging of installers
The former are defacto API we should document and are confident work consistently. The latter are inconsistent and I wouldn't rely on today, but some of them contain useful functionality that we should bless and make consistent. In general env-vars should be preferred since powershell and shell disagree on conventional cli argument naming so it's more straightforward to tell users "this is how you set vars in xyz, now here are the vars".
Definitely Works
These are definitely tested protocol, and we should document/guarantee them. Although INSTALLER_NO_MODIFY_PATH maybe wants to be renamed to match INSTALL_DIR? If it is we'll keep the old one working fine since there's no maintenance cost on that.
{APP_NAME}_INSTALL_DIR=/path/to/dir/: used to tell the installer the "base" dir to install to (this may have things like./bin/appended to them to satisfy your install dir structure, so it's not necessarily the dir the bins get installed to. Formalizing/documenting this is #934 and #1233).- aka
CARGO_DIST_FORCE_INSTALL_DIR
- aka
INSTALLER_NO_MODIFY_PATH=1: used to tell the installer to skip all the logic that tries to edit rcfiles or the registry to persistently add the dir to PATH--no-modify-pathin shell-NoModifyPathin powershell
Sourced As A Matter Of Course
Some other env-vars get read as a matter of course, and are not per se "configuration".
See #934 and #1233 for some planned changes here.
- install path vars
$HOMEis you use either the CARGO_HOME or~/sub/dirinstall-path$CARGO_HOMEif you have the CARGO_HOME install-path$MY_ENV_VARif you have the$MY_ENV_VAR/sub/dirinstall-path
- path vars
$GITHUB_PATHwill be modified if we see it, to force CI tasks to immediately put the installed app on PATH without a source/restart$PATHmay be checked to see if the install dir is already on PATH
- receipt vars (used to write install receipt used by updater)
$HOME($HOME/.config/{app_name}) in shell$LOCALAPPDATAfor ($LOCALAPPDATA/{{ app_name }}in powershell- #1355
Debug Stuff
- base download url: a url to a "directory" containing all the artifacts we might want to fetch. download urls are created by appending the artifact name to the url. This is not something users should really be messing with.
INSTALLER_DOWNLOAD_URLin shell-ArtifactDownloadUrlin powershell
- verbose: print extra messages to debug the installer
INSTALLER_PRINT_VERBOSEin shell-v, --verbosein shell-Verbosein powershell
- quiet: print less messages
INSTALLER_PRINT_QUIETin shell-q, --quietin shell- probably some equivalent in powershell from builtin params, but it's non-obvious
It'd be great to include {APP_NAME}_INSTALL_DIR and INSTALLER_NO_MODIFY_PATH in the installer help menu.
e.g., it's currently:
❯ curl -LsSf https://astral.sh/uv/install.sh | sh -s -- --help
uv-installer.sh
The installer for uv 0.4.10
This script detects what platform you're on and fetches an appropriate archive from
https://github.com/astral-sh/uv/releases/download/0.4.10
then unpacks the binaries and installs them to
$CARGO_HOME/bin (or $HOME/.cargo/bin)
It will then add that dir to PATH by adding the appropriate line to your shell profiles.
USAGE:
uv-installer.sh [OPTIONS]
OPTIONS:
-v, --verbose
Enable verbose output
-q, --quiet
Disable progress output
--no-modify-path
Don't configure the PATH environment variable
-h, --help
Print help information