The new build process, introduced in #13100 , relies on a spec's dependents in addition to their dependencies. Loading a spec from a yaml file was not initializing the dependents.

- [x] populate dependents when loading from yaml

…15197)

The distributed build PR (#13100) -- did not check the install status of dependencies when using the `--only package` option so would refuse to install a package with the claim that it had uninstalled dependencies whether that was the case or not.

- [x] add install status checks for the `--only package` case.
- [x] add initial set of tests

This is a minor permission fix on the new installer.py introduced in #13100.

This is a minor permission fix on the new installer.py introduced in #13100.

…15197)

The distributed build PR (#13100) -- did not check the install status of dependencies when using the `--only package` option so would refuse to install a package with the claim that it had uninstalled dependencies whether that was the case or not.

- [x] add install status checks for the `--only package` case.
- [x] add initial set of tests

The new build process, introduced in #13100 , relies on a spec's dependents in addition to their dependencies. Loading a spec from a yaml file was not initializing the dependents.

- [x] populate dependents when loading from yaml

This is a minor permission fix on the new installer.py introduced in #13100.

With the addition of #13100 (parallel builds), people are going to try to
run Spack in the background more often.  This makes Spack handle that
situation gracefully, the way a good POSIX program should.

Specifically:

1. When `spack install` is running, we disable echo and canonical input
   so that users can type `v` to toggle build output.  We do that in a
   safe way now, so that it does not generate `SIGTTOU` in the background
   (#14682 did this).

2. We properly disable keyboard input mode when Spack is placed in the
   background, and re-enable it when Spack is in the foreground.  This
   means that if you Ctrl-Z a spack install, your terminal won't be left
   in a weird state.

3. We'll continue writing verbose output when Spack is in the background.
   If you have `stty +tostop` on, it'll end up stopping the build when
   you try to run in the background, unless you redirect output. This is
   normal behavior and it lets you easily do thingslike `spack install &>
   log.txt &`

4. Spack works fine when stopped in the background or when running in the
   background.

(2) is handled mostly with signal handlers (the way things like `vi` and
`emacs` do it) -- see the code for how that's done -- it's a bit tricky
in Python, as Python did not support blocking signals until 3.8.  It
turns out we can still make it work.

With the addition of #13100 (parallel builds), people are going to try to
run Spack in the background more often.  This makes Spack handle that
situation gracefully, the way a good POSIX program should.

Specifically:

1. When `spack install` is running, we disable echo and canonical input
   so that users can type `v` to toggle build output.  We do that in a
   safe way now, so that it does not generate `SIGTTOU` in the background
   (#14682 did this).

2. We properly disable keyboard input mode when Spack is placed in the
   background, and re-enable it when Spack is in the foreground.  This
   means that if you Ctrl-Z a spack install, your terminal won't be left
   in a weird state.

3. We'll continue writing verbose output when Spack is in the background.
   If you have `stty +tostop` on, it'll end up stopping the build when
   you try to run in the background, unless you redirect output. This is
   normal behavior and it lets you easily do things like this:

       spack install -v &> log.txt &

4. Spack works fine when stopped in the background or when running in the
   background.

(2) is handled mostly with signal handlers (the way things like `vi` and
`emacs` do it) -- see the code for how that's done -- it's a bit tricky
in Python, as Python did not support blocking signals until 3.8.  It
turns out we can still make it work.

With the addition of #13100 (parallel builds), people are going to try to
run Spack in the background more often.  This makes Spack handle that
situation gracefully, the way a good POSIX program should.

Specifically:

1. When `spack install` is running, we disable echo and canonical input
   so that users can type `v` to toggle build output.  We do that in a
   safe way now, so that it does not generate `SIGTTOU` in the background
   (#14682 did this).

2. We properly disable keyboard input mode when Spack is placed in the
   background, and re-enable it when Spack is in the foreground.  This
   means that if you Ctrl-Z a spack install, your terminal won't be left
   in a weird state.

3. We'll continue writing verbose output when Spack is in the background.
   If you have `stty +tostop` on, it'll end up stopping the build when
   you try to run in the background, unless you redirect output. This is
   normal behavior and it lets you easily do things like this:

       spack install -v &> log.txt &

4. Spack works fine when stopped in the background or when running in the
   background.

(2) is handled mostly with signal handlers (the way things like `vi` and
`emacs` do it) -- see the code for how that's done -- it's a bit tricky
in Python, as Python did not support blocking signals until 3.8.  It
turns out we can still make it work.

With the addition of #13100 (parallel builds), people are going to try to
run Spack in the background more often.  This makes Spack handle that
situation gracefully, the way a good POSIX program should.

Specifically:

1. When `spack install` is running, we disable echo and canonical input
   so that users can type `v` to toggle build output.  We do that in a
   safe way now, so that it does not generate `SIGTTOU` in the background
   (#14682 did this).

2. We properly disable keyboard input mode when Spack is placed in the
   background, and re-enable it when Spack is in the foreground.  This
   means that if you Ctrl-Z a spack install, your terminal won't be left
   in a weird state.

3. We'll continue writing verbose output when Spack is in the background.
   If you have `stty +tostop` on, it'll end up stopping the build when
   you try to run in the background, unless you redirect output. This is
   normal behavior and it lets you easily do things like this:

       spack install -v &> log.txt &

4. Spack works fine when stopped in the background or when running in the
   background.

(2) is handled mostly with signal handlers (the way things like `vi` and
`emacs` do it) -- see the code for how that's done -- it's a bit tricky
in Python, as Python did not support blocking signals until 3.8.  It
turns out we can still make it work.

With the addition of #13100 (parallel builds), people are going to try to
run Spack in the background more often.  This makes Spack handle that
situation gracefully, the way a good POSIX program should.

Specifically:

1. When `spack install` is running, we disable echo and canonical input
   so that users can type `v` to toggle build output.  We do that in a
   safe way now, so that it does not generate `SIGTTOU` in the background
   (#14682 did this).

2. We properly disable keyboard input mode when Spack is placed in the
   background, and re-enable it when Spack is in the foreground.  This
   means that if you Ctrl-Z a spack install, your terminal won't be left
   in a weird state.

3. We'll continue writing verbose output when Spack is in the background.
   If you have `stty +tostop` on, it'll end up stopping the build when
   you try to run in the background, unless you redirect output. This is
   normal behavior and it lets you easily do things like this:

       spack install -v &> log.txt &

4. Spack works fine when stopped in the background or when running in the
   background.

(2) is handled mostly with signal handlers (the way things like `vi` and
`emacs` do it) -- see the code for how that's done -- it's a bit tricky
in Python, as Python did not support blocking signals until 3.8.  It
turns out we can still make it work.

A bug was introduced in #13100 where ChildErrors would be redundantly
printed when raised during a build. We should eventually revisit error
handling in builds and figure out what the right separation of
responsibilities is for distributed builds, but for now just skip
printing.

- [x] SpackErrors were designed to be printed by the forked process, not
      by the parent, so check if they've already been printed.

A bug was introduced in #13100 where ChildErrors would be redundantly
printed when raised during a build. We should eventually revisit error
handling in builds and figure out what the right separation of
responsibilities is for distributed builds, but for now just skip
printing.

- [x] SpackErrors were designed to be printed by the forked process, not
      by the parent, so check if they've already been printed.

A bug was introduced in #13100 where ChildErrors would be redundantly
printed when raised during a build. We should eventually revisit error
handling in builds and figure out what the right separation of
responsibilities is for distributed builds, but for now just skip
printing.

- [x] SpackErrors were designed to be printed by the forked process, not
      by the parent, so check if they've already been printed.
- [x] update tests

A bug was introduced in #13100 where ChildErrors would be redundantly
printed when raised during a build. We should eventually revisit error
handling in builds and figure out what the right separation of
responsibilities is for distributed builds, but for now just skip
printing.

- [x] SpackErrors were designed to be printed by the forked process, not
      by the parent, so check if they've already been printed.
- [x] update tests

A bug was introduced in #13100 where ChildErrors would be redundantly
printed when raised during a build. We should eventually revisit error
handling in builds and figure out what the right separation of
responsibilities is for distributed builds, but for now just skip
printing.

- [x] SpackErrors were designed to be printed by the forked process, not
      by the parent, so check if they've already been printed.
- [x] update tests

As of #13100, Spack installs the dependencies of a _single_ spec in parallel.
Environments, when installed, can only get parallelism from each individual
spec, as they're installed in order.  This PR makes entire environments build
in parallel by extending Spack's package installer to accept multiple root
specs.  The install command and Environment class have been updated to use
the new parallel install method.

The specs and kwargs for each *uninstalled* package (when not force-replacing
installations) of an environment are collected, passed to the `PackageInstaller`,
and processed using a single build queue.

This introduces a `BuildRequest` class to track install arguments, and it
significantly cleans up the code used to track package ids during installation.
Package ids in the build queue are now just DAG hashes as you would expect,

Other tasks:

- [x] Finish updating the unit tests based on `PackageInstaller`'s use of
      `BuildRequest` and the associated changes
- [x] Change `environment.py`'s `install_all` to use the `PackageInstaller` directly
- [x] Change the `install` command to leverage the new installation process for multiple specs
- [x] Change install output messages for external packages, e.g.:
       `[+] /usr` -> `[+] /usr (external bzip2-1.0.8-<dag-hash>`
- [x] Fix incomplete environment install's view setup/update and not confirming all 
       packages are installed (?)
- [x] Ensure externally installed package dependencies are properly accounted for in 
       remaining build tasks
- [x] Add tests for coverage (if insufficient and can identity the appropriate, uncovered non-comment lines)
- [x] Add documentation
- [x] Resolve multi-compiler environment install issues
- [x] Fix issue with environment installation reporting (restore CDash/JUnit reports)