New "curl-sh" installation method now available

[pkgw]

Hi folks,

In an effort to make it easier to install Tectonic I've set up the infrastructure for the "curl-based" form of installation that's become popular lately. On Unix-like platforms (including macOS) you should now be able to install Tectonic just by running:

curl --proto '=https' --tlsv1.2 -fsSL https://drop-sh.fullyjustified.net | sh

On Windows, it's a PowerShell two-liner:

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072
iex ((New-Object System.Net.WebClient).DownloadString('https://drop-ps1.fullyjustified.net'))

In both cases these scripts drop the tectonic executable in the current directory.

The main documentation hasn't yet been updated since I want to allow a little bit for folks to test things out in case I've made any silly mistakes. So please give it a try!

Implementation

If you're curious, the implementation of this "drop-in installer" functionality goes as follows. The number of moving parts might surprise you!

The actual installation scripts are hosted through the Tectonic organization's GitHub pages repo, and were added in tectonic-typesetting/tectonic-typesetting.github.io#38. The tricky bit is that the installer scripts need to know the version of the latest Tectonic release, and we really want that information to be updated automatically whenever a release is made. The CI system in the main Tectonic repo already has automation to update the website for releases, and I figured out how to use Jekyll's templating functionality to auto-update those scripts as part of the general website update.

But the URLs of those scripts aren't the prettiest. So I also wanted to create some relatively friendly domain names that could be used to access the installers. The fullyjustified.net infrastructure, which runs on Azure, is defined through Terraform files in the tectonic-cloud-infra repo, and in tectonic-typesetting/tectonic-cloud-infra#1 I added the definitions of the new domain names and routed them to a simple nginx-based web app that handles basic redirections for various pieces of the Tectonic web infrastructure. (That pull request also contains a bunch of other general updates.) The trickiest part with this is setting up proper HTTPS support, which is always a bit tedious.

Finally, in tectonic-typesetting/tectonic-relay-service#4 I added a little new logic to that web app to handle the new subdomains as vhosts and redirect as desired. I already had the nginx server set up with some vhost support, so this was pretty straightforward. The CI for this repo builds and updates the tectonictypesetting/relay-service Docker image when the main branch is updated, and the Azure web app is set up to automatically reload whenever that image is updated. So all I needed to do to get the new redirects running was to merge to master and wait a few minutes for the deployment to run.

[pkgw]

With tectonic-typesetting/tectonic-typesetting.github.io#40, the main website now highlights the curl-sh installation method: https://tectonic-typesetting.github.io/en-US/install.html

[aaronmurniadi]

This is awesome!

In both cases these scripts drop the tectonic executable in the current directory.

A little bit nitpicky, but is it possible to automatically download/move the tectonic binary into one of the $PATH directories?

In my opinion, with how the script behaves right now, it is just a download script and not an installation script.

[pkgw]

That's not unreasonable!

I have a pet peeve where I don't like scripts that assume that, say, $HOME/bin is a good place to install programs, so if we were to have this functionality I'd want it to figure out the right destination intelligently. Which I think would have to involve something like looking at $PATH, figuring out which directories are writable by the user, and choosing one of them. All of which seems complex and error-prone (e.g. you don't want to choose a Conda environment directory — the user should be installing a package for that), and I'm not aware of any lightweight installers that do something like that without ending up going the whole length of creating their own directory, editing .bashrc, etc. And at that point I feel like you might as well just use a real package manager. So my feeling is that the best balance is to drop the binary in the current directory and let the user go the "last mile" of placing it in a $PATH directory if/how they want.

I suppose we could finish by giving the user a menu of writable $PATH directories and giving them the option of moving the binary into one of them, or leaving it in place. From a theoretical perspective it feels like you're hardly making things are more convenient at that point, but I can see how it might seem nicer?

[pkgw]

Hmm, maybe it would be fun to have a little tectonic-installer helper program written in Rust, which could do all of the above without having to get into the dangerous world of trying to write ultra-portable shell script ...

[aaronmurniadi]

Thank you for your time addressing my comment.

I agree with all your points above.
You definitely have thought about this more than I did. 👍

I suppose we could finish by giving the user a menu of writable $PATH directories and giving them the option of moving the binary into one of them, or leaving it in place.

I think this could be the way. We could give a suggestion to place the binary into one of the well-known user $PATH directories like $HOME/.local/bin after running the script. Or, to cd into the available $PATH directory before running the script.