First of all, thanks for providing this dotfiles solution. I've used it already since at least 2012 according to my git history, and it has worked flawlessly throughout all the years!
Background
Lately the XDG Base Directory Specification has been gaining quite a steady popularity, even though it's been around for a long time already. The basic idea is to standardize where programs put their files e.g. all config files in a certain directory. The benefits for end users are many, including:
No polluted $HOME/
Can easily grep for only config files in $XDG_CONFIG_HOME
Can decide where to store configurations in more complex setups (multi system setup e.g.)
Easily wipe state by removing $XDG_STATE_HOME or even $XDG_DATA_HOME, but without destorying and configuration files.
The first point is maybe what most end users enjoy the most though.
How
As this project is the one actually setting up dotfiles, this subject becomes a bit meta. But basically the goal is the following: dfm should support looking at
$source_dir/.config/dfm/install or fallback to current
$source_dir/.dfminstall
By allowing the placement of the install file in .config/dfm/, this file will be able to be found (after dfm install) in the default XDG config directory where configuration files should be.
my $dfm_install = _load_dfminstall("$source_dir/.dfminstall");
to check if $source_dir/.config/dfm/install exist first and use that if found.
So most people will have XDG_CONFIG_DIR being the default value $HOME/.config. But what about if someone actually have set a non-default value; how would .config/dfm/install related to that? I was figuring in that case, this person can in their dotfiles repo do git mv .config/dfm/install .custom-non-default-config-path/dfm/install.
Edit.
~/.backup should probably live in $XDG_DATA_HOME/dfm/backup
First of all, thanks for providing this dotfiles solution. I've used it already since at least 2012 according to my git history, and it has worked flawlessly throughout all the years!
Background
Lately the XDG Base Directory Specification has been gaining quite a steady popularity, even though it's been around for a long time already. The basic idea is to standardize where programs put their files e.g. all config files in a certain directory. The benefits for end users are many, including:
$XDG_CONFIG_HOME$XDG_STATE_HOMEor even$XDG_DATA_HOME, but without destorying and configuration files.The first point is maybe what most end users enjoy the most though.
How
As this project is the one actually setting up dotfiles, this subject becomes a bit meta. But basically the goal is the following: dfm should support looking at
$source_dir/.config/dfm/installor fallback to current$source_dir/.dfminstallBy allowing the placement of the install file in
.config/dfm/, this file will be able to be found (afterdfm install) in the default XDG config directory where configuration files should be.In my own dotfiles repo, I did a PoC https://github.com/erikw/dotfiles/commit/0a0230c5cfbdf1908e934d19d9dbba6f19e90a68 and it seems to a rather isolated change. It's just a matter of modifying the 3 identical lines
to check if
$source_dir/.config/dfm/installexist first and use that if found.So most people will have
XDG_CONFIG_DIRbeing the default value$HOME/.config. But what about if someone actually have set a non-default value; how would.config/dfm/installrelated to that? I was figuring in that case, this person can in their dotfiles repo dogit mv .config/dfm/install .custom-non-default-config-path/dfm/install.Edit.
~/.backupshould probably live in$XDG_DATA_HOME/dfm/backup