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

Consider moving to platform-specific configuration directories #247

Open
brson opened this Issue Apr 1, 2016 · 27 comments

Comments

@brson
Copy link
Contributor

brson commented Apr 1, 2016

Many people would prefer cargo/rustup conform to various platform-specific standards for storing configuration. cc rust-lang/cargo#2127

(This issue was originally about a different subject, but is now an XDG etc. thread, some comments may make less sense out of context).

@gyscos

This comment has been minimized.

Copy link

gyscos commented Apr 5, 2016

I may have missed the answer before, but why not use XDG specifications again? (${XDG_DATA_HOME}/rustup)

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Apr 5, 2016

@gyscos It's because cargo doesn't. That's a change that all Rust tools need to make together.

@ollie27

This comment has been minimized.

Copy link

ollie27 commented Apr 6, 2016

That's a change that all Rust tools need to make together.

Why?

The issue with cargo is that it was released using the wrong directories so now it's a lot harder to change. If rustup uses the correct directories from the start then there isn't a problem and seeing as is has to be moved anyway there isn't even any backwards compatibility issues for people using the beta.

On windows for example it should be something like %LocalAppData%\rustup.

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Apr 6, 2016

Why?

Consistency is important. If you know where one Rust tool puts its stuff you know where they all do.

@ollie27

This comment has been minimized.

Copy link

ollie27 commented Apr 6, 2016

Well I reckon changing both cargo and rustup at the same time is going to be harder than just changing cargo.

Is knowing where the .rustup folder is important?

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Apr 7, 2016

@ollie27 I think it is yes. Like with .cargo, .git etc sometimes it's convenient to poke at internals. With rustup it seems to be important to know where the toolchains are stored for example.

@gyscos

This comment has been minimized.

Copy link

gyscos commented Apr 7, 2016

Putting things in the XDG folders doesn't make them opaque and inaccessible. Printing the path to downloaded toolchains (or showing this information in a rustup show command or anything) could help further.

Since cargo and rustup use different folders, I'd argue consistency is already lost (it's not like we had a ~/.rust directory with everything related - nor that this would be a better solution). If we can afford to rename rustup's folder while keeping it separate, then it makes sense to lead by the example and directly take the correct destination.

@kamalmarhubi

This comment has been minimized.

Copy link
Contributor

kamalmarhubi commented Apr 27, 2016

On OS X it'd be nice to use ~/Library/Applicacation Support (eventually?).

@critiqjo

This comment has been minimized.

Copy link

critiqjo commented May 14, 2016

The preferences crate can help with finding the platform-specific app-directory base, but it is not as great as appdirs yet.

Personally, I don't mind the status quo, since we have CARGO_HOME and RUSTUP_HOME environment variables.

@flying-sheep

This comment has been minimized.

Copy link

flying-sheep commented May 14, 2016

I'm really frustrated at the amount of projects deciding they're special snowflakes that don't need to follow standards.

Let's fix this now, before rustup is out of beta, to have inertia into the right direction.

@Diggsey

This comment has been minimized.

Copy link
Contributor

Diggsey commented May 14, 2016

rustup (when it was known as multirust-rs) used to follow the standard, at least for windows and mac, but was changed back to match the behaviour of cargo. If we're to make the change now it will need to be a concerted effort across the two projects with a well-tested upgrade path. I'd certainly like to make the change but it just hasn't been a priority, when there are so many other things that need doing.

@flying-sheep

This comment has been minimized.

Copy link

flying-sheep commented May 14, 2016

exactly that’s what always happens and what frustrates me. decisions like that are implemented ad-hoc, the fixes put on backburner, and once people would have time for it there’s suddenly inertia in the wrong direction and people have built tools relying on the hacky ad-hoc behavior that was never meant to last.

we have to switch now or we will do it never.

and to be honest, we should have thought about that from the inception.

@flying-sheep

This comment has been minimized.

Copy link

flying-sheep commented May 14, 2016

i also have no idea why there should be any reason to coordinate with cargo. can’t we use XDG and cargo later?

@mrhota

This comment has been minimized.

Copy link

mrhota commented Jun 19, 2016

@brson if this is something all Rust tools should do at the same time, does that mean it's RFC material?

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Jun 21, 2016

@mrhota Since it impacts so much of the ecosystem moving to platform-specific locations is probably RFC worthy, yes. It's probably important to be aware of all the activity in this cargo thread. cc @alexcrichton

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Jun 21, 2016

@flying-sheep I prefer to keep Rust's tooling consistent about this. Cargo and rustup are very closely related.

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Jun 21, 2016

This thread is about moving away from the multirust name though. Please do open a different thread do discuss XDG etc.

Edit: on second thought this thread is sufficiently about XDG now that I'll just change the op and make a new issue for the rename.

@brson brson changed the title Move ~/.multirust to ~/.rustup Consider moving to platform-specific configuration directories Jun 21, 2016

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Jun 21, 2016

cc #537

@liigo

This comment has been minimized.

Copy link

liigo commented Jun 23, 2016

It's a chance to discard .multirust directory.

@ssokolow

This comment has been minimized.

Copy link

ssokolow commented Jul 15, 2016

I really don't feel like screwing around with countless "special snowflake" applications, each with its own "move the profile" environment variable.

I run into enough games that put their configuration files in $HOME as NON-hidden directories and bypass $HOME using functions like getpwuid that, if I can't containerize them, I'll probably be implementing some kind of LD_PRELOAD shim to make functions like getpwuid lie about where ~ is and/or silently rewrite paths passed into functions like fopen.

(Ideally, the containerization, since that won't be outwitted by static linking)

Regardless of whether this is fixed, I'll come up with some kind of single-command (probably at install time) solution to force things like rustup and cargo to stop making a mess, whether they like it or not.

@flying-sheep

This comment has been minimized.

Copy link

flying-sheep commented Jul 15, 2016

I really don't feel like screwing around with countless "special snowflake" applications, each with its own "move the profile" environment variable.

yeah, i also really like to do ls ~/.config and get a list of configurable software ❤️

@retep998

This comment has been minimized.

Copy link
Member

retep998 commented Jul 15, 2016

I just want rustup out of my home directory and into AppData. There is absolutely no reason for dot directories on Windows, especially since 1. they're a pain to work with and 2. it doesn't actually hide the folder. So please, be nice and move it to AppData, probably Local.

@chris-morgan

This comment has been minimized.

Copy link
Member

chris-morgan commented Jul 16, 2016

@retep998 You can, of course, attrib +h %USERPROFILE%\.multirust. But then, people working in Rust on Windows probably have it set to show hidden files anyway.

@frewsxcv

This comment has been minimized.

Copy link
Member

frewsxcv commented Jul 16, 2016

Would this change the path for configuration files for OSX users?

@ollie27

This comment has been minimized.

Copy link

ollie27 commented Jul 17, 2016

I think the important discussion is exactly which directories we should be using. Obviously we should be following OS conventions where possible, that goes without saying.

On Windows I think %LOCALAPPDATA%\rustup makes the most sense.
On Linux I think $XDG_DATA_HOME/rustup with a fallback to ~/.local/share/rustup will follow the XDG Base Directory Specification nicely.

The binaries are currently installed in Cargo's bin directory which I assume is so you only have to add one thing to the $PATH. Are there any other reasons?

I suggest moving them as well to perhaps to %LOCALAPPDATA%\rustup\bin and ~/.local/bin on Windows and Linux respectively. This should mean that rustup will no longer care about Cargo's directories which will simplify things significantly. On some Linux distros like Fedora it will mean you don't have to add anything to the $PATH and with rust-lang/rfcs#1615 the binaries will be next to those installed with cargo install if that's important.

What do other people think? Also what directories should be used on OS X?

@fenhl

This comment has been minimized.

Copy link

fenhl commented Jul 17, 2016

@ollie27 command-line tools on OS X should use the same directories as on Linux, i.e. those defined in the XDG Base Directory spec.

@soc

This comment has been minimized.

Copy link

soc commented Apr 14, 2018

Heads up:

Work on cargo is underway in rust-lang/cargo#5183.

The fix for rustup will be next.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.