Strip out wrapper and env files to submodule

[Thaodan]

Hey,

Thanks for the inspiration to continue on this task to clean out my home and structure my configs.

I was wondering if it makes sense to put all the parts of your repo that bend programs to adhere to the xdg specific or to be exact this ~/.local structure.
Your approach is quite similar to the emacs-package no-littering.
Maybe something like xdg-no-littering would be nice.

This way your approach can be reused by a wider base of users.

[ayekat]

I'm currently inclined not to do such a thing.

Splitting off the wrapper scripts into (a) separate submodule(s) would mean putting engineering efforts into having a "cleaner" approach to wrapping tools. But I'm putting "cleaner" in quotes there because I believe that the wrappers are already a hack to begin with (also briefly discussed in issue #23) and efforts for pushing applications towards XBDS compliance are probably better put into the respective upstream projects themselves.

(that's obviously pretty utopic, as we know that there's upstream maintainers who explicitly refuse to comply with the spec, but one can always dream 😅)

A second, less idealistic (but more pragmatic) reason is that I want to avoid splitting up maintenance of my personal setup more than it is already. Especially if one part of it becomes sort of "ready to use" for other people, it means more maintenance burden for me (maintaining the modules, interacting with users, and just in general having one more moving part in my ecosystem).

After all, there's a reason why I explicitly mark this repo as This is my stuff, I do it my way, don't expect it to work for your usecase in the readme; it "frees" me from the pressure of having to adhere to other people's expectations (but I do welcome suggestions, so yours is still very much welcome!) 🙂

Also note that this doesn't mean that I won't change my mind about this in the future.

[Thaodan]

No problem, I get it. After cleaning up my $HOME, researching which adapted and which not I'm already annoyed my self..

Ideally your solution should work for anyone since it doesn't do much besides putting everything in $HOME/.local.

It is so annoying how some apps behave, GPG for example changes the socket paths if you change GPGHOME..

[ayekat]

GPG for example changes the socket paths if you change GPGHOME..

From what I can see, GPG keeps its sockets in $XDG_RUNTIME_DIR/gnupg. Or does it put its sockets elsewhere if GNUPGHOME is unset?

[Thaodan]

Tinu Weber ***@***.***> writes:

> GPG for example changes the socket paths if you change GPGHOME.. From what I can see, GPG keeps its sockets in $XDG_RUNTIME_DIR/gnupg. Or does it put its sockets elsewhere if GNUPGHOME is unset?

The path is still in that directory puts a hash of the path of GNUPGHOME in between the socket file and the base path. Check: https://wiki.archlinux.org/title/XDG_Base_Directory#Partial https://github.com/gpg/gnupg/blob/260bbb4ab27eab0a8d4fb68592b0d1c20d80179c/common/homedir.c#L710-L713 https://wiki.archlinux.org/title/GnuPG#gpg-agent