I just added the ability to auto-set --dirty by setting the env var SPACK_DIRTY. This is a good thing because on our supercomputer, nothing works without certain modules loaded. Hence the need for the "dirty" environment.

I don't want to be typing spack install --dirty all the time. And due to the nature of Spack commands, I couldn't do this as an alias either (because the --dirty flag would mess up other Spack commands).

HOWEVER... I'm not sure an env var is the right place to put this. Maybe it should be going into a global Spack config, some YAML file? Advice?

probably this PR could solve your problem #943

@tgamblin This is technically ready to merge. This PR does three things:

1. Fix bug propagating --dirty to sub-modules
2. Expand --dirty beyond spack install to other cmds where it is logical.
3. Allow you to set a SPACK_DIRTY env var instead of using the --dirty flag. That's because (a) people don't want to say --dirty everywhere on systems that need it, and (b) you can't do alias spack=spack --dirty.

Before merging, we need to decide whether an env var is the right way to create a "permanty --dirty". Or should we put an entry into one of Spack's config files? If so, which one, and how do we code that?

I want to allow an entry in config.yaml when it appears (soon). It'll be a top-level config for most o the things in spack/__init__.py I'd rather stay away form env vars for this. I think it's too easy to be unintentionally dirty.