example use case: at my job we use jsonnet to render our k8s manifests. that tool chain also depends on perl (don't ask), kubecfg, and jsonnet-bundler there are multiple repos that depend on this tool chain, but there are at least two different ways the dependencies are managed. for a couple of reasons i don't want to just dump the tools into a container, and i'd like to be able to dynamically download and install specific versions of these tools on the fly. i also want to be able to support multiple different versions across the different repos that use them, so it needs to support different install paths for different versions. ways i'm aware of to solve this problem: - built it into the repos (via shell script or

Makefile

or something) - ultimately would work, but i'm worried about conversion and ongoing maintenance costs - containers - don't love the overhead, especially b/c we'd need mount volumes and a lot of disk i/o through a container can get really slow - our CI is going to run stuff as-is and i don't want to have to think about docker-in-docker (or to rewrite all our CI to support the migration) - nix shell - i really thought this was going to be my solution, but it gets very cumbersome very quickly if you want to support a version that isn't the bleeding edge - it adds an unnecessary dependency: the nixpkgs repo itself - i recently had to work with kubecfg's maintainers to get a patch in upstream. if we were already using nix, i would have had to get a patch in to nixpkgs after the kubecfg patch landed and before we could use the new version - asdf - as far as i'm aware this is much more for supporting different versions of language interpreters, not tools (eg different versions of python or node) - ansible, maybe? - i don't know a lot about ansible but i think this is probably too heavy to the point that it would be better to build it into the tooling already in the repo rather than also manage ansible

features i'd like: • lightweight ◦ single binary ◦ root never required ▪︎ not to install the tool itself ▪︎ the tool should not need it to install the additional tools in the tool chain ◦ "drop-in" as much as possible • support multiple installs of different versions of the same tool • no additional dependencies between the tools and our use ◦ see the nixpkgs problem above • works in and out of containers