Env vars modified explicitly by packages are shielded from module

[alalazo]

fixes #8632

@mgsternberg Can you check if it solves your issue?

[mgsternberg]

Intriguing and cleverly implemented, but doesn't that go too far?

Suppose a DAG member sets PATH and LD_LIBRARY_PATH for its internal use, and who knows what else. Consider thatintel-mkl sets CPATH, as does intel-parallel-studio. Could the blanket shielding not easily undermine a compiler module, without possibility of an override?

[alalazo]

You're right: the devil is in the details. PATH can be a real issue: it's set in the build environment in python, lua, tcl and a few other relevant packages. So is, surprisingly, CPATH. LD_LIBRARY_PATH is more of a theoretical problem, as no package sets it at build time - I think due to the RPATH philosophy of Spack.

Could the blanket shielding not easily undermine a compiler module, without possibility of an override?

We need for sure to implement some heuristics if we go this route, as you correctly pointed out. On the other hand I think that also switching the order of compiler loading requires some care in that sense - in that case we need to be sure we don't unset CPATH, LD_LIBRARY_PATH etc. if they are needed for the compiler to work correctly.

[alalazo]

Superseded by #9107