Follow XDG Base Directory Specification
jtrv opened this issue · 3 comments
What is the problem this feature would solve?
The .dedoc/ directory unnecessarily pollute users' $HOME directory.
What is the feature you are proposing to solve the problem?
The XDGBDS defines where these files should be placed with environment variables to avoid polluting the $HOME directory.
From the XDGBDS:
The XDG Base Directory Specification is based on the following concepts:
There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable
$XDG_DATA_HOME.There is a single base directory relative to which user-specific configuration files should be written. This directory is defined by the environment variable
$XDG_CONFIG_HOME.There is a single base directory relative to which user-specific state data should be written. This directory is defined by the environment variable
$XDG_STATE_HOME.There is a single base directory relative to which user-specific executable files may be written.
There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable
$XDG_CACHE_HOME.User-specific executable files may be stored in
$HOME/.local/bin.
Implementing XDGBDS should work as follows:
IF a corresponding XDG environment variable exists THEN use it's location according to the spec.
ELSE If the corresponding XDG environment variable is not defined, the program must fallback to the specified defaults:
| env | fallback |
|---|---|
| XDG_DATA_HOME | ~/.local/share |
| XDG_CONFIG_HOME | ~/.config |
| XDG_STATE_HOME | ~/.local/state |
| XDG_CACHE_HOME | ~/.cache |
So the default/fallback directory layout mapping for now should be:
| current | xdg compliant |
|---|---|
| ~/.dedoc | ~/.local/share/dedoc |
For me this is a controversial issue. I change operating systems very often, and I often need to use both Linux and Windows. My biggest complaint with the software is that they all use different paths to their configuration on different platforms. Take familiar neovim for example. On Linux it is may be located in ~/.config/nvim, on Windows it is located in ~/AppData/Local/nvim. And sometimes I need to work with a lot of software that does this. These tricks waste my time searching the directory and often require memorizing paths instead of doing the things that matter. Maybe I just prefer having it in my $HOME.
My biggest complaint with the software is that they all use different paths to their configuration on different platforms. Take familiar neovim for example. On Linux it is may be located in
~/.config/nvim, on Windows it is located in~/AppData/Local/nvim.
I understand your concern, but it seems reductive to disregard all specifications due to the case of switching OS's, and the ambiguities of Windows spec. This then makes a mess for all users on all OS's.
For example I personally have ~330 explicitly installed packages from the Arch Repositories / AUR, and ~120 shell tools in cargo/bin (many of which are cross-platform) that follow the specification, with the exception of a few that at the very least provide workarounds reported in https://github.com/b3nj5m1n/xdg-ninja. Because of this my $HOME is able to remain organized and tidy.
If every project ignored XDGBDS, I would easily have >200 .program_name directories in $HOME and my system would be a mess and a pain to navigate.
Only 2 programs on my system use folders in $HOME similar to dedoc, and both have issues tracking in progress, with plenty of comments and reactions from users expressing interest.
If you are willing to adhere to the spec, dirs should make this fairly easy, I might make a PR if I get a chance.
If not then at the very least I would suggest checking for a $DEDOC_HOME in the environment as a workaround.
@toiletbril would you consider reviewing #9 ?