FWIW, I'm all for this. Admittedly I would prefer that it go further, especially making it possible to make a spack self-contained with a file on disk, but any step in this direction seems like a good one to me.

I've been submitting pull requests for several years about this issue and would be happy to see something done about it. I haven't understood the reluctance of the Spack team to make the user config path overridable by an environment variable - this is a defector standard way of customizing applications in the Linux/HPC worlds. I've got two comments on this specific PR:

• this seems overly complicated. Why not just do

  user_config_path = os.getenv('SPACK_USER_CONFIG_PATH', os.path.expanduser('~/'))

  This can be simply tested with the following test:

  import os
  from spack.util.executable import Executable
  import spack.paths
  def test_user_config_path():
      spack_script = os.path.join(spack.paths.bin_path, 'spack')
      spack_python = Executable('{0} python'.format(spack_script))
      env = os.environ.copy()
      user_config_path ='foo/baz'
      env['SPACK_USER_CONFIG_PATH'] = user_config_path
      spack_python(
          '-c',
          'import spack.paths; assert spack.paths.user_config_path == {0!r}'.format(user_config_path),
          allow_failure=True,
          env=env,
      )
      assert spack_python.returncode == 0

• this PR does not go far enough. It needs to replace occurrences of ~/.spack in $spack/etc/spack/defaults/config.yaml with $user_config_path. @trws has an alternative PR that does this. Without this, spack will still write to ./spack

for several years

this PR does not go far enough.

Please read the first paragraph, the PR is simple to get it in, hopefully before 0.17 branches off, for which the window is narrowing.

Adding $user_config_path adds a new feature people will start to rely on. That may reduce chances of getting this in, since there are plans to drop the config scopes in the future (and I don't want to get into that in this PR). Note that the only relevant config setting you're talking about is misc_cache: ~/.spack/cache. After you've moved your user config to $SPACK_USER_CONFIG_PATH/config.yaml, just set the config:misc_cache value there.

Why not just do

See the reply above, there are plans to gradually get rid of all the spack globals and put them in some config/context object, which allows us to do unit testing of its initialization without side effects. Your test works too and is side effect free but starting a python subprocess was again something I feared would spark discussion blocking the actual contribution. Unit testing _get_system_config_path at least resembles the future unit test for default settings in spack.

Thanks for the reply @haampie - I'll just register my opinion that I think pulling in SPACK_USER_CONFIG_PATH without the corresponding change to the default misc_cache is a step backwards. I have a fork of Spack that I administer that applied a similar patch to your PR. User's were very angry that Spack kept trying to write to ~/.spack when they set SPACK_USER_CONFIG_PATH to something else. These user's were happy with the default configuration and did not want to write a config.yaml just to get spack to write the misc. cache to user_config_path. After applying a patch to write misc. cache where it should be (user_config_path) the complaints stopped.

I still maintain this fork of spack and many dozen users at Sandia use it - once this issue is resolved we will all happily ditch the fork and use the mainline spack.

Calling it a step back is not helpful if you really want something along these lines to be merged. And it really is not, cause: (a) it's enabling you to opt out of ~/.spack as a source where config is read from, which was previously impossible. And (b) you can give better defaults to your angry users by setting config:misc_cache:[some path] e.g. ~/.spack/cluster-name/cache, $scratch/spack-cache, or $SPACK_USER_CONFIG_PATH/.spack/cache in $SPACK_SYSTEM_CONFIG/config.yaml.

For further discussion please resort to #12892.

github actions doesn't want it to be merged, maybe just drop the pr?

=================================== FAILURES ===================================
________________________ test_list_format_version_json _________________________

    @pytest.mark.maybeslow
    def test_list_format_version_json():
        output = list('--format', 'version_json')
>       assert '  {"name": "cloverleaf3d",' in output
E       assert '  {"name": "cloverleaf3d",' in '[\n  {"name": "3dtk",\n   "latest_version": "1.2",\n   "versions": ["trunk", "1.2"],\n   "homepage": "http://slam6d.s...topcf",\n   "latest_version": "1.0.5",\n   "versions": ["1.0.5"],\n   "homepage": "https://cgit.freedesktop.org/x\n]\n'

lib/spack/spack/test/cmd/list.py:58: AssertionError
!!!!!!!!!!!!!!!!!!!! Interrupted: stopping after 1 failures !!!!!!!!!!!!!!!!!!!!
== 1 failed, 2429 passed, 7 skipped, 22 xfailed, 5 xpassed in 1106.24 seconds ==

same issue in another pr of mine

It’s done y’all!

yay

So I tested this out while also linking ~/.spack -> /dev/null to catch anything else. I end up with this error:

==> Error: [Errno 20] Not a directory: '/Users/svc-dashboard/.spack/bootstrap'

So there are still bits that want to touch ~/.spack around.

@mathstuf Did you use both SPACK_DISABLE_LOCAL_CONFIG and SPACK_USER_CACHE_PATH? If you don’t use the latter, caches like bootstrap store will still default to the home directory.

Yep:

        SPACK_USER_CACHE_PATH: "$GIT_CLONE_PATH/.gitlab/spack-cache"
        SPACK_DISABLE_LOCAL_CONFIG: "true"

So, this is because $user_config_path is not magically gone if you use SPACK_DISABLE_LOCAL_CONFIG 🙃

This means that you still have to override all config settings that use $user_config_path or use SPACK_USER_CONFIG_PATH.

I think the better solution now is to get rid of SPACK_DISABLE_LOCAL_CONFIG, it's mostly confusing.

Instead stick to SPACK_USER_CONFIG_PATH, SPACK_SYSTEM_CONFIG_PATH and SPACK_USER_CACHE_PATH.

@mathstuf: can you send a debug trace for the failure you mentioned above? (run with spack -d)

Do you refer to user_config_path in your configuration? Is that where it's coming from?

My guess would be it's this biting us: https://github.com/spack/spack/pull/26735/files#diff-24ac473c44f26728fd3da17d5dd741c4073fa0d8aec651971c2aaf7d17747c9fR7

That still needs to go somewhere, probably fall back to the next config scope like the rest of spack does?

@mathstuf: can you send a debug trace for the failure you mentioned above? (run with spack -d)

I'll try and get a run with this in.

Do you refer to user_config_path in your configuration? Is that where it's coming from?

Not that I know of. The entirety of the Spack on the machine (besides the ~/.spack tripwire) is in this script (I removed the noisy Linux setup parts):

        SPACK_USER_CACHE_PATH: "$GIT_CLONE_PATH/.gitlab/spack-cache"
        SPACK_DISABLE_LOCAL_CONFIG: "true"

#!/bin/sh

set -e

readonly spackroot="$CI_PROJECT_DIR/.gitlab/spack"

# Clone Spack itself.
git clone --depth 1 https://github.com/spack/spack "$spackroot/src"
export SPACK_ROOT="$spackroot/src"
export PATH="$PATH:$SPACK_ROOT/bin"

# Search for the compiler.
spack compiler find

# Clone mochi package repository.
git clone --depth 1 https://github.com/mochi-hpc/mochi-spack-packages "$spackroot/mochi"

# Add mochi repo to Spack.
spack repo add "$spackroot/mochi"

# Inject CI tools to avoid builds.
mkdir -p "$spackroot/config"
cat > "$spackroot/config/packages.yaml" <<EOF
packages:
  all:
    target: [$( uname -m )]
  cmake:
    buildable: false
    externals:
    - spec: cmake@$( cmake --version | head -n1 | cut -d' ' -f3 )
      prefix: $CI_PROJECT_DIR/.gitlab/cmake
EOF

readonly spec="mochi-thallium@main^libfabric fabrics=tcp,rxm"

# Install thallium.
spack -C "$spackroot/config" install $spec

# Clean up the directory.
spack -C "$spackroot/config" clean

@mathstuf: I think I've fixed this over in #27022 -- gripping around for hard-coded .spack references. I assumed the variables in spack.paths were actually being used as defaults here and that was clearly wrong.