Add support for the XDG Base Directory Specification
severen opened this issue · 8 comments
I recommend storing:
~/.multirust/toolchains
under$XDG_DATA_HOME/multirust
.~/.multirust/default
,~/.multirust/overrides
and~/.multirust/version
under$XDG_CONFIG_HOME/multirust
.~/.multirust/cache
and~/.multirust/update-hashes
under$XDG_CACHE_HOME/multirust
.
You can find the specification here.
This blog post lists the advantages of using the XDG Base Directory Specification as follows:
$HOME
is a lot less cluttered.- Backups are a lot more safer and easier (you know that creating a backup of your
$XDG_DATA_HOME
along with your files is enough). - A lot easier to reset a default configuration if you want/need it (and without any risk of loosing information).
- Avoid some strange bugs that happen because you had a old version of some configuration file.
- It is a lot more flexible and portable because no paths are hard-coded. You can use the XDG library that does the job for you or, if you don’t want the dependency, implementing the XDG specification is only a few lines of code.
Thanks for the suggestion. It's worth considering for a future revision of the metadata.
My major concern with relying on XDG is that it isn't portable to systems that don't implement XDG. Splitting multirust's data into multiple directory also loses the simplicity of being able to override MULTIRUST_HOME
.
I wouldn't be against making this an opt in feature for the people who do want it. Perhaps have a file or configuration key for indicating that the user has opted in to using the XDG spec?
EDIT: Or maybe use an environment variable? (Something like: $MULTIRUST_XDG_ENABLED
)
Yes, it seems like it would need to be optional.
How about defaulting to XDG if ~/.config/multirust is present?
@jck why would that be a more desirable way to activate XDG than $MULTIRUST_XDG_ENABLED
? Perhaps because its easy to accidentally not set the environment variable and use the wrong config?
Because people usually just symlink folders from their dotfiles repo to XDG_CONFIG_HOME. This way, they don't have to set an additional environment variable.
How about checking if ${XDG_DATA_HOME:-$HOME/.local/share}/multirust
is present or not in the multirust
script? That is, the installation folder itself can be used as a flag. install.sh --xdg
can create it beforehand.