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 · 29 comments
Open

Consider moving to platform-specific configuration directories #247

brson opened this issue Apr 1, 2016 · 29 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
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
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
Copy link
Member

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

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

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

@critiqjo
Copy link

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

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

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

@mrhota
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
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
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
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
Copy link
Contributor Author

brson commented Jun 21, 2016

cc #537

@liigo
Copy link

liigo commented Jun 23, 2016

It's a chance to discard .multirust directory.

@ssokolow
Copy link

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

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

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

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

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

@ollie27
Copy link
Member

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

@luis-guimaraes-exoawk
Copy link

The pull request mentioned by @soc was closed without merging... This is still an important feature

@LucasFA
Copy link

LucasFA commented Feb 13, 2024

For anyone interested, there's a pre-RFC in the forums:
https://internals.rust-lang.org/t/pre-rfc-split-cargo-home/19747

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

No branches or pull requests