spacemacs-cache-directory is ignored in dotspacemacs/*-init

[zabbal]

Description

spacemacs-cache-directory variable is ignored when set in dotspacemacs/user-init or dotspacemacs/init
After closing Spacemacs the .cacheis created in the old location with auto-save subdirectory and spacemacs-buffer.el files
If that's the expected behavior and it should be set someplace else than it would be great to get this documented.

Reproduction guide 🪲

• Set spacemacs-cache-directory in dotspacemacs/user-init to non-default value, for example "~/.cache/emacs/"
• Close Spacemacs

Observed behaviour: 👀 💔
.cache is re-created at old location

Expected behaviour: ❤️ 😄
The value of spacemacs-cache-directory should be used.

System Info 💻

• OS: gnu/linux
• Emacs: 25.2.2
• Spacemacs: 0.200.13
• Spacemacs branch: master (rev. c7a103a)
• Graphic display: t
• Distribution: spacemacs
• Editing style: emacs
• Completion: helm
• Layers:

(helm auto-completion better-defaults emacs-lisp git github markdown jabber semantic ibuffer mu4e emoji c-c   csv emacs-lisp ess go graphviz haskell scala shell-scripts org themes-megapack command-log finance pandoc pdf-tools restclient systemd search-engine
      (shell :variables shell-default-height 30 shell-default-position 'bottom)
      spell-checking syntax-checking version-control)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

[ViktorHaag]

This might be because the default location of the cache directory gets set in core-load-paths.el (and the location of spacemacs-auto-save-directory and pcache-directory gets set based on that initial value), so if you reset it later (in dotspacemacs/user-init or dotspacemacs/init), the auto-saves and pcache will still go into the original location, I'd expect.

[zabbal]

So there's another variable in addition to spacemacs-cache-directory which governs the location, sets differently and has higher priority? That's highly confusing and seems like a bug to me - it's better to have single source of truth for this kind of stuff.

[ViktorHaag]

So there's another variable in addition to spacemacs-cache-directory which governs the location, sets differently and has higher priority?

What I mean to say is that spacemacs-cache-directory gets set in /core/core-load-paths.el, and then

• spacemacs-auto-save-directory gets set to its string value, via expand-file-name
• pcache-directory uses its value, via (concat "pcache/")
• the cache directory gets created if it doesn't already exist

These things all happen before (presumably) user init configuration can happen in .spacemacs, so the directory will get created, containing the pcache, and auto-save directory set there.

Presumably, then, if you wanted to do something else via .spacemacs, you'd need to move three things not just one, and I'm not sure if spacemacs uses any of these directories before your user settings happen (it's possible stuff could get cached in pcache, maybe?).

In my fork (on the develop branch), I rearranged core-load-paths.el and built the cache directory relative to user home, and not relative to spacemacs-start-directory, but not everyone would be comfortable tweaking the core engine that way, I would guess...

Given the way that spacemacs seems to be organized, I'm not sure there would actually be a better way to set the cache directory for user preference without messiness... I guess that there could be a higher level setting exposed in .spacemacs which, if set, spacemacs would move things around after the fact (but that seems really messy)... there may well be a reason that spacemacs core needs to set and have ready the cache directory so early in the init process.

[zabbal]

I wonder if XDG support in upcoming Emacs 27 could help to resolve this.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

[zabbal]

The issue is still valid.

[lebensterben]

The issue is still valid.

@zabbal Does this problem exist on develop branch?

[ViktorHaag]

@lebensterben -- I believe it does, yes; my remarks above were all made in the context of using the develop branch... (I've edited my remarks above to make that more clear).

[zabbal]

What's the point of reporting issues if they'll be closed by some bot regardless of the comments anyway?

[duianto]

This one fell through the cracks, and we didn't remove the stale label in time.
Sorry about that.

A recent commit seems to indicate that this might be handled automatically in the future:
[CI] remove stale label when issue updated a862d1a

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!