Summary

We want to make Spack XDG-compliant. That should probably happen in #47615.

• Most things could live in XDG_DATA_HOME (and several should)
• XDG_DATA_HOME could change, and I think we should do a couple slightly-XDG-noncompliant things to account for that
• the spec describes some other variables/locations for other broad categorizations of files (e.g. configs) and suggests that we store our files there; we should for the sake of convention, but doing so won't yield any benefit
• Conforming to this spec doesn't make any part of Shared spack #47615 easier, just adds complication (I still think we should do it, but I think it's worth clarifying that it doesn't solve any problems for us)

Details

The XDG spec is at https://specifications.freedesktop.org/basedir-spec/latest/. Debian has a table at the end of https://wiki.debian.org/XDGBaseDirectorySpecification that I think is extremely helpful in thinking about what these variables could/should actually mean. The following list mentions all variables and summarizes their intended use (based on the two links I provided):

• XDG_DATA_HOME: the only place for large amounts of persistent data
  • XDG_DATA_DIRS: alternate locations
• XDG_CONFIG_HOME: persistent but not for large amounts of data (for config files by convention, but IMO not really essential to have on top of XDG_DATA_HOME)
  • XDG_CONFIG_DIRS
• XDG_STATE_HOME: technically persistent, but by convention for things that are not essential
• XDG_CACHE_HOME: for large amounts of data; purge-able on log-out
• XDG_RUNTIME_DIR: for things like sockets and named pipes; according to the spec it must be cleared on reboot; overall the spec puts more words into defining this than any other variable, although it isn't generally useful for us

The following covers the various bits of state in spack and what XDG_ destinations they should live in

what                where            avoid-default notes
misc caches         XDG_STATE_HOME  
gpg keys            XDG_DATA_HOME                  2
cached downloads    XDG_DATA_HOME    y             3
modules             XDG_DATA_HOME   
managed envs        XDG_DATA_HOME    y             1i
user scope config   XDG_CONFIG_HOME 
installs            XDG_DATA_HOME    y             1, 5
build stages        n/a              y             4

1. (update May 14) installs take up too much space for us to put them in the default location of XDG_DATA_HOME (which is the only suitable spot for them).
   1. For environments, XDG_CONFIG_HOME is the most-suitable location for the spack.yaml, but at the moment, specs can store source for develop specs, and also views, so they take up too much space for that (or the default value of XDG_DATA_HOME)
2. based on XDG_ variable properties described in https://wiki.debian.org/XDGBaseDirectorySpecification, XDG_STATE_HOME would be suitable, but the spec's described use for XDG_STATE_HOME doesn't match (XDG_STATE_HOME is for storing things like open files for an editor)
   1. ? should private keys generated by Spack be (a) backed up (b) version controlled and/or (c) synced across machines?
3. XDG_CACHE_HOME is tempfs: not long-lived enough
4. If XDG_CACHE_HOME is set explicitly, it would be suitable. We default to tmp ($tempdir/$user/spack-stage), so using it is less important. Either way, we should always avoid using the default value of XDG_CACHE_HOME
5. What happens if XDG_DATA_HOME is set, and then set to something else? 1. For installs, we should read this once and store that location in $HOME/.config (this is the default for XDG_CONFIG_HOME, but my point is we don't want to check XDG_CONFIG_HOME because that could change too)

General information

• I have searched the issues of this repo and believe this is not a duplicate