[mlthoughts2018]

Before containers and even widespread VMs, “thick archives” basically just meant a tar file that contained all of the build tooling in addition to the project code.

So you might create an archive with a whole compiler toolchain and shell scripts / makefiles to invoke it locally on the host machine.

Usually a project would have a build system that auto-generated these archives for any combination of platform / compiler options targeted for support. So you’d choose the MacOS archive if you use a Mac (maybe further separated based on your architecture’s precision and which compiler, etc.)

It leads to a Chinese Menu problem of multiplicity: archive files for X platforms times Y precisions times Z compilers, etc. (especially painful for embedded devices).

It’s a reasonable way to ship the entire build artifacts though.

VMs are a perfectly good way to distribute reproducible research. Though I think containers are the best way currently because of the usability of most container APIs (standard recipes & build experience, managed container repos, etc.).

In principle you could build convenience APIs around thick archives or VMs too, it just seems less common for whatever reason.