brson/multirust

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.
brson commented

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)

brson commented

Yes, it seems like it would need to be optional.

jck commented

How about defaulting to XDG if ~/.config/multirust is present?

brson commented

@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?

Similar thread on Cargo.

jck commented

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.

brson commented

@nodakai I'd prefer that, but I'm still not convinced it's the right thing to do.

If multirust supports XDG we also need to care about where cargo is putting its data, and right now they are not planning on adding XDG I think.