Those bugs and PRs would just get closed without comment. Nobody is going to move a dotfile as a breaking change in any established software. You either get it right the first time or probably never.
That could break some peoples’ dotfile management, e.g. symlinks or git repos. I’d say deprecation notice and reading from both, at least for a while, is better.
I know developers are busy, and I don’t mean to berate them for their choices or work. I only have a two year Computer Information Systems degree and haven’t programmed a lot for a while, but supporting the XDG specification and remaining backwards compatible doesn’t seem to be very difficult or would cause so much breakage (of course, the amount of work would depend on the software and how the hardcoded path is implemented). I look up git repository issues for the software and tend to find ubiquitous examples like vim to be resistant to such change: https://github.com/vim/vim/issues/2034
This is really frustrating and leads me to find alternative software, such as neovim/doom emacs instead of vim, nushell instead of bash, etc., just to be able to clear up my home directory. I don’t mind if I have to wait for XDG to be supported, but many important projects just label the issue as “won’t fix”. I totally understand where you are coming from.
If you install config files to the new location and prefer the new config file location over the old, you risk accidental misconfiguration when a system has both config files (e.g. in a build pipeline that installs the software and then copies the config to the old location). It is not impossible to solve, but there are questions that require some care if you have a large userbase and solidified codebase. More care than it takes to do it right the first time.
A (very well used) program I use places files in $HOME. Someone argued for changing to $XDG_CONFIG or at least add that as an option. The dev, being used to the old school way, gave the exact opposite reason: that .config was just an extra level of organization when dotfiles are what the home dir is for. So I’m not sure how successful you would be with that approach.
To be clear, I am clearly on the side of XDG, myself.
If you care, please take time to upvote or file bugs on packages that don’t follow XDG. Or even better, make PRs.
Those bugs and PRs would just get closed without comment. Nobody is going to move a dotfile as a breaking change in any established software. You either get it right the first time or probably never.
The software can read from both locations in a backwards compatible way. Many tools already do this.
The best way to handle this is to have the next version move the old directory (if it exists) and then start reading from there.
That way it’s in compliance from then forward.
A UI notice is nice but will probably be ignored.
That could break some peoples’ dotfile management, e.g. symlinks or git repos. I’d say deprecation notice and reading from both, at least for a while, is better.
I know developers are busy, and I don’t mean to berate them for their choices or work. I only have a two year Computer Information Systems degree and haven’t programmed a lot for a while, but supporting the XDG specification and remaining backwards compatible doesn’t seem to be very difficult or would cause so much breakage (of course, the amount of work would depend on the software and how the hardcoded path is implemented). I look up git repository issues for the software and tend to find ubiquitous examples like vim to be resistant to such change: https://github.com/vim/vim/issues/2034
This is really frustrating and leads me to find alternative software, such as neovim/doom emacs instead of vim, nushell instead of bash, etc., just to be able to clear up my home directory. I don’t mind if I have to wait for XDG to be supported, but many important projects just label the issue as “won’t fix”. I totally understand where you are coming from.
List of software with hardcoded paths at this time: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded
You can add the proper location to the list of possible dirs. Fhen you can movd your dotfile
If you install config files to the new location and prefer the new config file location over the old, you risk accidental misconfiguration when a system has both config files (e.g. in a build pipeline that installs the software and then copies the config to the old location). It is not impossible to solve, but there are questions that require some care if you have a large userbase and solidified codebase. More care than it takes to do it right the first time.
True
A (very well used) program I use places files in $HOME. Someone argued for changing to $XDG_CONFIG or at least add that as an option. The dev, being used to the old school way, gave the exact opposite reason: that .config was just an extra level of organization when dotfiles are what the home dir is for. So I’m not sure how successful you would be with that approach.
To be clear, I am clearly on the side of XDG, myself.
XDG is a Red Hat thing.
Stuff outside of their influence is unlikely to change, like OpenSSH or ZSH.
Old things like that get a pass. New tools and frameworks should definitely obey the standards.