mistydemeo
commented
4 months ago Reading over how it does it, seems pretty reasonable for us to adopt the same strategy. We'll keep the logic of OS and arch detection within the shell/powershell scripts, but everything past that can get moved into Rust.
Similar to how axoupdater itself works, we'll probably want an "axoinstaller" library within this crate(?) which performs the installations, and an installer binary that's a thin layer on top of that.
The primary complication I can think of is that we make extensive use of inlining data into the installer script at the time cargo dist build happens, and that's obviously a lot less practical in the case that most of the installer logic is in Rust. The difference between us and rustup is that our installers have all the knowledge they need to know about both the location of an installer package and its contents baked into itself. We can still bake it into the shell half, but we'll need to be able to communicate it from the shell side to the Rust side.
The installer.sh and installer.ps1 scripts in cargo-dist are a hybrid of rustup's installer bootstrap scripts and this rust code.
In rustup the installer scripts just handle detecting target triple, unpacking the archive into a tempdir and then run the rustup binary to finish installing itself. Updating rustup at that point is rustup itself doing the fetch and unpack, and again running its new self.
This is honestly the ideal way for an installer to work, as it gives the cli dev all the room in the world to add custom install logic/output in a way that's a pain with shell. Plus, rust code is a lot easier to maintain/test/trust than random shell scripts. In an ideal world we could actually share code with rustup and mutually improve/maintain this updater logic.
There are three features here: