Would you like to help keeping ~/.emacs.d clean?

[tarsius]

I have just published an extremely early version of the no-littering package. From its description:

The default paths used to store configuration files and persistent data are not consistent across Emacs packages. This isn't just a problem with third-party packages but even with built-in packages.

Some packages put these files directly in user-emacs-directory or $HOME or in a subdirectory of either of the two or elsewhere. Furthermore sometimes file names are used that don't provide any insight into what package might have created them.

This package sets out to fix this by changing the values of path variables to put files in either no-littering-etc-directory (defaulting to ~/.emacs.d/etc/) or no-littering-var-directory (defaulting to ~/.emacs.d/var/), and by using descriptive file names and subdirectories when appropriate. This is similar to a color-theme; a "path-theme" if you will.

We still have a long way to go until most built-in and many third-party path variables are properly "themed". Like a color-theme, this package depends on user contributions to accomplish decent coverage. Pull requests are highly welcome.

Something like this only has a change at succeeding if enough people contribute and I though that maybe some of the people who maintain and contribute to Spacemacs would be interested to help out. Would you consider adding this to Spacemacs (of course only after it is a bit more complete)? Any suggestions/questions/...?

[bmag]

To me this sounds like a good idea, that is going to benefit both Spacemacs and the broader Emacs community 👍

Spacemacs uses spacemacs-cache-directory, which defaults to ".emacs.d/.cache", as the location for these files. Searching the codebase for spacemacs-cache-directory and .cache should show all the cache files that Spacemacs handles.

[syl20bnr]

We can help to add support for the various variables we set to .cache directory but using this package does not fit Spacemacs architecture which isolates package configuration in init functions. Variables related to a package are set in its respective init function. Centralizing variables at some place may confuse users, lead to inconsistencies about what component is responsible for what and introduce latencies to support new variables.

[syl20bnr]

There is one advantage of such package that makes me reconsider my position on this:
There are some packages installed as dependencies (ie: no Spacemacs configuration comes with them) and still pollute the root folder.

So I'm OK to move to this package :-)

[tarsius]

There are some packages installed as dependencies (ie: no Spacemacs configuration comes with them) and still pollute the root folder.

My motivation to create this package was similar; my init file contained some use-package instances which contained nothing but changes to path variables, and I wanted to avoid that. (1)

So I'm OK to move to this package :-)

Good to hear! I haven't worked on it since I opened this issue but now that it has your approval it's getting more likely that I will invest some time to compile a basic variable collection. I would like to give you and @justbur commit access. No obligation comes with that but it does mean that you can add settings as you see fit, without necessarily having to get my approval every time. If you actually go ahead and use this in Spacemacs, and should I be absent for a while, and then it would be unfortunate if you couldn't make necessary changes.

Also this would be a good idea to discuss basic design decision. Using cl-flet at the top-level is a bit strange, but it does get the job done. But if you have a better idea... Then again we can still change that later.

Likewise, do you have an suggestions on how files should be named? Should we always use a subdirectory if a package has more than one config/persistent file? Etc. We should try to soon make up our minds about such questions.

---

(1) And I already had a borg-based starter-kit/distribution in mind. (If you have no idea what I am talking about, start here: Assimilate Emacs packages using Git submodules.)

When using such a (for now hypothetical) starter-kit, users enable "layers" by merging branches. Of course maintaining layers as branches means that there will be merge conflicts and a borg-based starter-kit would therefore only be suitable for users who are not afraid of that.

Since Spacemacs targets a much more diverse user-base, using Borg wouldn't make sense. Nevertheless I would be interested in hearing your thoughts on Borg (and am secretly hoping someone will create a Spacemacs fork that uses Borg, if only as a proof-of-concept, but that's probably wishful thinking).

Even though a borg-based starter-kit is only intended for users who are not afraid of merge conflicts, it is still a good idea to avoid unnecessary conflicts. Having to configure a package just because it puts its config and persistent files in unfortunate places would result in such unnecessary conflicts. That was a major motivation for creating this package. I think it is a good thing to keep path settings separate from other configuration. At least when using Borg but I think that might also the case in the context of Spacemacs.

[syl20bnr]

If you actually go ahead and use this in Spacemacs

Sure! :-)

Should we always use a subdirectory if a package has more than one config/persistent file?

I'm for it, a folder with the name of the package, the same name than in elpa directory but without the version info. For built-in libraries we can find the most obvious feature name.

For the implementation I have no opinion on it, let's first make it work and put things at the correct place.

Since Spacemacs targets a much more diverse user-base, using Borg wouldn't make sense. Nevertheless I would be interested in hearing your thoughts on Borg (and am secretly hoping someone will create a Spacemacs fork that uses Borg, if only as a proof-of-concept, but that's probably wishful thinking).

Currently Spacemacs uses quelpa which can fetch packages given a MELPA recipe, I'm not an expert of those recipes, maybe they can already do what submodules allow. In the eventuality it does not we can add a :location submodule for packages and use borg behind the scene.

[syl20bnr]

quelpa is used with :location (recipe :fetcher github etc....)

example here: https://github.com/syl20bnr/spacemacs/blob/develop/layers/+lang/php/packages.el#L21

[tarsius]

I'm for it, a folder with the name of the package, the same name than in elpa directory but without the version info. For built-in libraries we can find the most obvious feature name.

That's the idea, yes ;-)

For the implementation I have no opinion on it, let's first make it work and put things at the correct place.

Well, @justbur has already begun tweaking the implementation (emacscollective/no-littering#3). So will end up doing both in parallel ;-)

Currently Spacemacs uses quelpa which can fetch packages given a MELPA recipe, I'm not an expert of those recipes, maybe they can already do what submodules allow. In the eventuality it does not we can add a :location submodule for packages and use borg behind the scene.

I think you misunderstood. no-littering can be installed using quelpa (or melpa) and always will be. (Well, I haven't created a recipe yet, but that's just boilerplate).

Borg is an alternative to package.el, it makes little sense to use both. I just mentioned Borg because I decided to implement no-littering while working on that. But it is completely independent - I thought it was worth mentioning why I have decided to take a stab at no-littering now.

And I was also hoping for a little feedback on Borg, that's all ;-)

[d12frosted]

Any updates? 😸

[tarsius]

If I understand the purpose of #7334 and its entry for this issue correctly, then this should be closed.

[braham-snyder]

FWIW, "Discussion over" looks to me like it was almost certainly just an unfortunate misinterpretation of the discussion in this issue

[tarsius]

I would still like if Spacemacs started to use this package ... so reopening.

[tarsius]

There are so many open issues that keeping this open won't make a difference. And I care about keeping my own todo lists short, so closing again.