Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for the XDG Base Directory Specification #104

Open
severen opened this issue Oct 15, 2015 · 8 comments
Open

Add support for the XDG Base Directory Specification #104

severen opened this issue Oct 15, 2015 · 8 comments

Comments

@severen
Copy link

severen commented Oct 15, 2015

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
Copy link
Owner

brson commented Oct 15, 2015

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.

@severen
Copy link
Author

severen commented Oct 16, 2015

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
Copy link
Owner

brson commented Oct 16, 2015

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

@jck
Copy link

jck commented Feb 2, 2016

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

@brson
Copy link
Owner

brson commented Feb 5, 2016

@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
Copy link

jck commented Feb 11, 2016

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.

@nodakai
Copy link
Contributor

nodakai commented Feb 27, 2016

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
Copy link
Owner

brson commented Feb 28, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants