@tgamblin @citibeth is there any chance of this, or one of the other similar, PRs being merged? This one issue, not being able to isolate spack instances from the user's spack configuration is the only thing keeping my group at SNL from pulling/using Spack from GitHub instead of our own fork. We must be able to guarantee that our software stack is built the same way every time and the only way possible is if we provide configuration scopes (or environment files) for building our stack - but it is all for not if there is something in the user's configuration that will change the build. Spack environments are great, but they are not a magic elixir because, AFAIK, they do not allow one to completely isolate a build from the user's settings. A single environment variable, as proposed here, fixes all of our issues whether using environments or custom configuration scopes.

@bartlettroscoe may also has other projects where spack integration is critical but where isolating Spack from the user's settings is a major thorn in the side.

@bartlettroscoe may also has other projects where spack integration is critical but where isolating Spack from the user's settings is a major thorn in the side.

We have other issues with Spack but one of the major drivers for our significant scripting layer around Spack is to get around this issue of not writing and reading to ~/.spack/. You can't safely run raw Spack commands the way things currently are.

Having to set an env var that points to a specific path is not ideal. I would be better if we could set an env var that tell Spack to read and write state only with the current working directory/environment space.

@bartlettroscoe wrote:

I would be better if we could set an env var that tell Spack to read and write state only with the current working directory/environment space.

What would that look like, and how would it be different than telling spack which path to read/write user settings from?

For our purposes we have a Spack fork and a module file that

setenv SPACK_USER_CONFIG_PATH "some path"

where some path points somewhere like /dev/null. we then provide spack.yaml and/or configuration scopes.

On other projects, I use that same Spack fork and set SPACK_USER_CONFIG_PATH to point to per project Spack configuration scopes. This way, each project is totally isolated from one another.

We did a fairly brutal lobectomy on spack to achieve that a while back, not sure if that commit still applies though 584e132eecff

@healther I don't see how that helps, the user configuration path is still set to

#: User configuration can override both spack defaults and site config.		
 _user_path = spack.user_config_path

which is hard coded to ~/.spack. This PR seeks to make the location of the user configuration path configurable through an environment variable.

@tjfulle For some reason I read this as an issue (as opposed to a PR). Your solution is clearly better.

Can confirm this works great. Used it productively to manage 10 spack stacks in one user home, no issues found.