Why is this better than makeself or similar, which don't suffer from the platform issue?

It seems a bit ugly to do this as part of the homepage generation. Would be better to add it to the Nix jobset and copy it to the release directory in the nix/maintainers/upload-release.pl script.

Why is this better than makeself or similar, which don't suffer from the platform issue?

Arx should be crossplatform. I’m not sure what platform issue you mean.

Also, makeself is IMO not as well designed. Specifically, piping will not work so curl | sh fails. See megastep/makeself#24.

@matthewbauer I just meant this thing you said:

Unfortunately, this also means that we will need 1 installer for each platform supported

What we really need is an ELF/Mach-O polyglot 😁

Oh well that would be necessary with makeself as well. The Nix installer is only built to handle 1 version of Nix. It's hardcoded here: https://github.com/NixOS/nix/blob/master/scripts/install-nix-from-closure.sh#L7.

We could rewrite it to make a "universal" installer that comes with tarballs for all supported systems, but that would increase download size 4x what it already is.

Okay redid this to avoid building Arx in nixos-homepage. PR is at #2135.

I have now redone the install script to show how to retain the "platform detection" of the original (so you don't have to know what your system name is ahead of time & curl https://nixos.org/nix/install | sh still works.

I think losing the .sig and the hash checking is a non-starter. I think the goal of having the installer not re-fetch the tarball on each run is a good one. I think this could be done with the existing installer process, by fetching to $TMPDIR/nix-x.x.x-system.tar.bz2 only if the file doesn't already exist with the expected hash. I'm a bit skeptical about using something other than well-known compression formats for the binary release history of Nix.

I think losing the .sig and the hash checking is a non-starter.

Yes this can be readded. I wasn't sure why .sig was there in the first place, though. Doesn't Curl's SSL do this for us already?

I think the goal of having the installer not re-fetch the tarball on each run is a good one. I think this could be done with the existing installer process, by fetching to $TMPDIR/nix-x.x.x-system.tar.bz2 only if the file doesn't already exist with the expected hash.

This is definitely good to do. But the root cause is that the average user will be downloading two different files, the install script & the tarball, which can be confusing. My thinking is it would be better to just bundle them together.

I'm a bit skeptical about using something other than well-known compression formats for the binary release history of Nix.

Well, you can always circumvent the nixos.org/nix/install route by downloading the binary tarball directly, if for instance you want versioned installs. This shouldn't change that. Arx is a little bit weird but the underlying compression would still be .tar.bz2. It's not that uncommon to use self-extracting scripts. For instance, makeself is used by VirtualBox, Google Earth, & nVidia.

Also, this is more of a POC for how an install process using Arx could work. First, we would want to merge NixOS/nix#2135 & establish that it works correctly for at least 1 release before making it the default.

Yes this can be readded. I wasn't sure why .sig was there in the first place, though. Doesn't Curl's SSL do this for us already?

the signature can be used to ensure every release was signed by the same person, and can provide an out-of-band way to validate the integrity of the tarball. It isn't used by the curl | sh workflow, only people who want to validate it via gpg first: https://nixos.org/nix/download.html. SSL (TLS) ensures the connection between the server and the client is trusted by a known certificate authority, but doesn't ensure the validity of the file being downloaded, for example if nixos.org's website was hacked.

This is definitely good to do. But the root cause is that the average user will be downloading two different files, the install script & the tarball, which can be confusing.

I won't guess what the average user would say, but this is also the result of the code in this PR now: the script and arx files are fetched separately, but still the arx file is not cached. Also, I don't think the root cause is the second download, I think the root cause is the second download is performed repeatedly and unnecessarily -- a pretty easy problem to fix.

the script and arx files are fetched separately, but still the arx file is not cached

Yes that's true & probably good reason why this doesn't make sense. I guess it's difficult to figure out because what I'd really like to do is create a "universal" installer that bundles everything into one file & can be used everywhere. But that's probably too much to download right now (download size would go from 20MB to 80MB). It might still be useful to distribute it as an alternative though. This script rewrite was kind of a compromise but doesn't really accomplish that original goal.