The use case I had in mind when I started the thread, and that I think we really don’t serve as well as we could, is when you want to quickly and automatically install a local “scratch” copy of a specific version of Python. For example, think of
toxtrying to run tests against 5 different Python versions, or
pipenvtrying to bootstrap an environment with a specific Python version, or a CI environment where I want to grab a nightly build for
$CURRENTPLATFORMand run tests.
spack: specs: - email@example.com - firstname.lastname@example.org - email@example.com
The workflow is:
$ git clone https://github.com/spack/spack $ . spack/share/setup-env.sh $ spack install
The recipe for Python is portable and works cross-platform.
You can also test more complicated matrices, e.g., 3 python versions built with
icc, with different flags, for different architecture targets:
spack: specs: matrix: - [firstname.lastname@example.org, email@example.com, firstname.lastname@example.org] - ["%gcc", "%intel"] - ["cflags=-O3", "cflags=-O2"] - [target=broadwell, target=skylake]
That’ll give you 24 different
python builds (it’s a Cartesian product).
- No windows support (yet).
- Spack builds from source by default, as we don’t (yet) have a public binary mirror for commonly build configurations. That’s something we’re working on. You can make a binary cache, which will create relocatable binaries so you don’t have to keep rebuilding the same matrix over and over.
Anyway, the caveats are probably a roadblock at the moment, but the tool is designed to build and package many different versions of “whatever”, which seems very close to your use case.