New, experimental console UI for the Spack installer that allows:

1. Spack to show progress on multiple parallel processes concurrently;
2. Users to view logs for different installations independently; and
3. Spack to share a jobserver among multiple parallel builds.

Demo: https://asciinema.org/a/7azU9idEnT8ydgxcRKxYBZzI2

Usage:

• Set config:installer to new (or use spack -c config:installer:new install ...)
• The -j flag in spack install -j <N> ... is all you need, it will build packages in parallel. The -p flag has no effect.
• Use n for next logs and p/N for previous logs
• Use v to toggle between logs and overview
• Use q or Esc to go from logs back to overview.
• Use / to enter search mode: filters the overview as you type; press Enter to follow logs or Esc to exit search mode.

Current features:

• create or use existing POSIX job server
• POSIX job server client
  • first build process token is implicit
  • second, third, ... build processes require token
  • do single read from jobserver pipe to try to obtain as many tokens as there are pending builds
  • schedule as many concurrent jobs as token/bytes obtained
  • test in practice with pstree <python pid>, it seems to work
  • hook onto existing jobserver when Spack runs under it
  • keep the --jobserver-auth=R,W pipes open in the subprocess in build processes in case Spack itself runs under an existing jobserver
  • set MAKEFLAGS in a subprocess based on the gmake version of the particular build: if gmake is new enough, pass the FIFO auth flag, if gmake is old, pass the file descriptors for the FIFO instead of the FIFO path.
• epoll/kqueue based event loop that wakes on:
  • stdin v (toggle log/overview), q (return to overview), n (next), p (previous), etc
  • jobserver token(s) available
  • SIGCHLD to deal with build success/failure
  • install phase changes from build processes
  • logs from build processes
  • fetch progress (currently not implemented in the build process, requires a callback in the fetcher)
• IO thread in build process with another epoll/kqueue based event loop
  • wake on stdout (build process has 2>&1 redirected)
  • wake on "1"/"0" bytes from "control" pipe from parent to toggle writing to parent pipe
  • forward stdout/stderr from build process to build log file and optionally to parent process
• responsive UI
  • overview mode that redraws every ~100ms with spinners for progress
  • log mode that follows stdout/stderr of one of the builds
  • explicit installs are always printed in bold
  • successful installs are persisted to terminal history
  • install prefix appears after successful install
  • narrower terminals show fewer details per build
  • builds are truncated with <n> more... on small terminals
• rate limit redraw calls
• "non-blocking" database writes
  • one attempt to obtain db write lock per iteration of the event loop (worst case ~100ms)
  • queue all specs to be persisted in the db in case of failure to obtain write lock
• source builds
• non-blocking install from build cache in subprocess
• pre/post install hooks
• build error handling