Compliance with XDG?

[jasonkarns]

I love the intent behind this project! (I’m personally responsible for a lot of “please respect xdg base dir spec” issues on tooling repos).

I am curious about things though. How does this pattern at the repository level work when systems have XDG_CONFIG_HOME set to something other than ~/.config? Ime, lots of well meaning devs implement .config “support” by hardcoding that path instead of respecting the environment variable. Then you have tools writing to the wrong location again! I’d be concerned that promoting .config at the repo level would increase the chances the tool also writes directly to ~/.config and didn’t actually respect the spec.

Another thought, can this site also promote proper use of XDG_CONFIG_DIRS? If tools begin supporting config files at multiple levels (repo and system), one would expect they support the multiple-dir path variable for that purpose?

And lastly (to a much lesser degree), I think there should probably be guidance to ensure tools don’t use the .config dir for non configuration files (particular, cache, state, or general data). Doing so at the repo level would most likely indicate violation of the spec at the system level as well.

I wonder if this project should also reference (and be referenced by!) the arch Linux support wiki? https://wiki.archlinux.org/title/XDG_Base_Directory#Support

great work!

[bkuhlmann]

Hey Jason. 👋 I'm curious about this too.

💡 I wanted to mention that I handle this gracefully in the Runcom gem (which is built upon the XDG gem). In a nutshell, Runcom obeys the XDG specification but will look to your repository first and fallback if otherwise. The documentation is up-to-date that explains how all of this works. I've been maintaining and using the Runcom gem for ~8 years now and use this in most of my CLIs, applications, etc.

In a sense, Runcom is the Ruby implementation of what this dot-config project is all about only Runcom gives you access to cache, data, and state in addition to config support. 🚀