Need for insights about uberenv

[cyrush]

this supported the case where

1. we had a cached build of all dependencies for CI to cut down on build times
2. but as part of CI it was very important for us to rebuild a few key dependencies as part of our process to vet changes

So it was really there as an optimization - mainly as we fought against time limits on CI services a compile times for TPLs grew.

The current logic works as follows:
All variants of any package identified in the spack_clean_packages list will fully uninstalled.

In your example, all (for any spec) will be uninstalled.

Also, for more context -- 99% of the time, I only use an uberenv spack build for 1 set of tpls.
I will use another checkout and build space for a different spec.
Perhaps thats a bit wasteful in space, and I think others might prefer multiple builds in a single instance -- but for me it simplifies things quite a bit, since there is no possible way to confuse what sets of tpls I am using when I pick up and use the host config.

[adrienbernede]

Thanks for the answer!

The underlying question remains, though:

• Should Uberenv support multiple installations?
  Your answer is telling me "probably". I think it should, but it may make the script a bit more complex (rigorous).

And your answer also brought another question:

• Do we still want to maintain this "time optimization feature" ?
  I would say no, since we could also use upstream Spack instances to get the same result.