create "ci" mode for ephemeral environments, with bare minimum env assumptions

[Gankra]

The installer does several things that are useful/important for the full breadth of its supported usecases, but which are unnecessary or detrimental for folks who want to take control of the installation process. As such, we need a way to reliably tell the installer "don't do anything clever, and don't error out for things that don't really matter here".

The original proposal was to just make it non-fatal for certain operations like the install-receipt to be non-fatal to setup. The only consequence of a failed receipt is the updater gets bricked. In really minimal CI-like systems the updater doesn't matter, so we should not fall over if the receipt fails.

However as we discussed this more, we realized there's more kinds of usecases and something more comprehensive/intentional was desirable.

[ashleygwilliams]

after chatting a bit more with zanie, i think we should keep the install receipt being fatal and introduce a --ci flag (very open to a different name) that is designed for ephemeral environments. it does not require any env vars to be set and it doesn't try to create receipts of any kind. i think having a fork and clearly naming the behavior is a better choice than muddying a single behavior mode

[ashleygwilliams]

relevant issue from astral's tracker https://github.com/astral-sh/uv/issues/6965#issuecomment-2334455056

[Gankra]

Ok so here's Notable things the installer does by default, in probably too much granularity, for the sake of discussion. Some of these things are statically baked into the installer when we generate it, while others are dynamically computed.

I've bolded the steps which I expect someone wanting to "just install the bins, no funny business" may want disabled/changed.

Step 1: What Are We Installing?

• platform detection
  • does a bunch of heuristic stuff to determine os/cpu/libraries
  • computes a rust-flavoured target triple
• archive selection based on platform
  • looks up a prioritized list of archives that can provide runnable binaries on that platform
  • checks runtime requirements like glibc version for each archive, selecting the first that works (or erroring)
  • this does stuff like musl-static fallback, rosetta2 fallback, etc

Step 2: Getting The Goods

• archive fetching
  • makes a tempdir to download/unpack to
  • constructs a url
  • determines whether to use curl/wget, and with what flags
  • downloads to tempdir
• archive unpacking
  • determines whether to use tar/unzip, and with what flags
  • unpacks archive to tempdir

Step 3: Installing

• install dir detection
  • queries relevant env-vars based on app developer's install-path settings
• install dir layout
  • determines which files should be unpacked from the archive (bins, dylibs, docs...)
  • determines to which subdirectories of the install-dir they should be unpacked
  • in the default configuration bins get placed in $install_path/bin
  • on unix sourceable env scripts gets made in $install_path/
• install receipt construction
  • a special install receipt with metadata about the install is added in another location
  • this receipt is used by the updater to determine if the binary we're looking at is presumed to be managed with other things like npm/pip/brew/apt -- without the receipt we assume it's managed and refuse to run the updater.
  • this means skipping this "bricks" the installer (which may be acceptable!)

Step 4: Updating PATH

• detect if bins are currently on PATH
• immediate path updating
  • if $GITHUB_PATH is detected that is edited to immediately help Github CI users with custom install dirs
  • updating $PATH is of course fruitless here because as soon as the installer returns the changes will be thrown out
• registering path changes in rcfiles/registry
  • some fairly complex logic to idempotently append source path/to/env/script into bashrc/.profile/...
  • some logic to idempotently edit user's default PATH in registry
• recommending user actions for current session
  • "source path/to/envscript"
  • "set Path=path/to/bins;%Path%"

[Gankra]

I expect every user still wants all of step 1 and 2. For steps 3 and 4 there are a few classes of user here that I'm familiar with:

• House Cleaners: This is the kind of user that got the rust devs made CARGO_HOME for. Often they just want to declutter HOME but don't otherwise care that much about the fact that the tool wants its own bin dir and install layout.
• Dir Structuralists: This is the kind of user who has wholy embraced some particular standard for where certain files should go, like XDG, and so really wants the bins to go in this specific dir, and probably don't want many side-effects if any.
• Automation Conductors: This is the kind of user who needs to setup a ton of tools in some uniform way. In practice they're similar to Dir Structuralists but they are likely to be in CI and might be have "strange" environments where $HOME doesn't exist. Probably they want absolutely no side-effects and just want us to get the bins downloaded and unpacked so they can immediately copy them somewhere else.

In practice I expect the structuralists and conductors basically want access to the same "mode":

• no install dir structure
  • use exactly the path i specify
  • don't append bin/
  • don't create env scripts
  • don't unpack docs
  • ??? cdylibs ??? (this doesn't affect most users like astral/uv but is a thing we support in general)
• no install receipt? (this is where i can imagine actual disagreement)
  • structuralists might actually want the updater to work
  • conductors don't care at all
• no rcfile/registry/path modifications
  • structuralists will have the location in PATH already
  • conductors are either the same or are going to relocate the bins immediately