document/bless installer args, and make sure they're consistent

[Gankra]

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 normalize install dir structure #934 and Feature: more install layouts #1233).
  • aka CARGO_DIST_FORCE_INSTALL_DIR
• 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-path in shell
  • -NoModifyPath in 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
  • $HOME is you use either the CARGO_HOME or ~/sub/dir install-path
  • $CARGO_HOME if you have the CARGO_HOME install-path
  • $MY_ENV_VAR if you have the $MY_ENV_VAR/sub/dir install-path
• path vars
  • $GITHUB_PATH will be modified if we see it, to force CI tasks to immediately put the installed app on PATH without a source/restart
  • $PATH may 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
  • $LOCALAPPDATA for ($LOCALAPPDATA/{{ app_name }} in powershell
  • fix: Make RECEIPT_HOME variable XDG compliant #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_URL in shell
  • -ArtifactDownloadUrl in powershell
• verbose: print extra messages to debug the installer
  • INSTALLER_PRINT_VERBOSE in shell
  • -v, --verbose in shell
  • -Verbose in powershell
• quiet: print less messages
  • INSTALLER_PRINT_QUIET in shell
  • -q, --quiet in shell
  • probably some equivalent in powershell from builtin params, but it's non-obvious

[zanieb]

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