Allow Spack environments to "chain" on top of others. For example, a sysadmin creates a Spack environment with some compilers and basic libraries. And a user builds a Spack environment, chained off of the first, that adds more application software to the stack. See discussion below...

Incremental builds / chained environments
In our development workflows we often have a local area that overlays a central base install area. For this to work, spack areas would need to be chainable. Being chainable requires:

1. for compile time a well-defined, cross-checked environment
2. for runtime the possibility of overriding libraries from the base area with ones from the local area. In particular most usage of RPATH would require to be replaced with RUNPATH. Unless using fully relocatable packages.

Could you elaborate further? I'm not sure I understand the details of this chained environment. I also suspect it might be the kind of thing that seems like a good idea when manually installing software, but is not so useful with Spack managing things.

Our use case is the following. We have central installations of plenty of packages, which are being used by O(100) developers. Now developers frequently build new packages or new versions of packages against these central installations. There is no way for every developer to set up a new stack from scratch for this. Thus a nice feature would be to enable developers to do things like:
spack external addarea /path/to/central/spack/install
spack install < new package building against central area >

OK, this sounds like a nice feature. As I see it, the idea might be to have the sysadmins manage Spack tree A, and I manage Spack tree B. Somewhere in the config for Spack tree B, I point it to A. B then sees all the packages in A. Is anyone opposed to such a feature?

Unfortunately, every nice feature comes with complications. Here are the ones I see:

1. The ideas we're working up on filling "holes" in the software DAG would have to take account of this:
   Security Updates #562
   In particular... suppose the sysadmins find that openssh-1.2.1 has a security problem, so they remove it from TreeA. Spack will not be able to tell whether its removal creates a hole, because it will not know what other trees might be using TreeA. I think we can figure this one out.
2. If TreeA and TreeB exist at arbitrary locations, then relative RPATHs ($ORIGIN) will no longer work when referencing packages between trees. MAYBE this can be solved if we use softlinks to create virtual super-trees of Spack software. For example...
   SpackVirtualEnv/
   TreeA --> /opt/spack/TreeA
   TreeB --> ~/spack/TreeB
   With such a setup, there will always be a predictable path between trees, as well as within a Spack tree.

Point 1) I don’t consider such a big problem. Point 2) looks to me like already thinking about an implementation path. Maybe here as well it is the time to open a new mail thread just dealing with this feature request. In case others find it useful.