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

Does rustfmt look in $HOME/.config/rustfmt on macOS? #4613

Open
jason5122 opened this issue Dec 28, 2020 · 3 comments · May be fixed by #6181
Open

Does rustfmt look in $HOME/.config/rustfmt on macOS? #4613

jason5122 opened this issue Dec 28, 2020 · 3 comments · May be fixed by #6181

Comments

@jason5122
Copy link

I see that rustfmt checks for a config file in $HOME/Library/Preferences/rustfmt. Does it also check in $HOME/.config/rustfmt? From my testing, it seems like it does not (assuming it's only on Linux that it does). If not, is there a chance that this could be supported? Thanks!

@calebcartwright
Copy link
Member

rustfmt's config file resolution process is documented here and the user config directory resolution is managed by the dirs crate (not rustfmt) and yes that directory path varies by OS: https://docs.rs/dirs/3.0.1/dirs/fn.config_dir.html

To be fully transparent, I'm not particularly keen on introducing an additional Mac-only phase to that probe path/resolution sequencing. However, if anyone feels strongly enough about this to submit a PR I'd be willing to review and consider incorporating it provided it wasn't too invasive and didn't add undo complexity and maintenance overhead.

@lilyball
Copy link

lilyball commented Nov 6, 2021

The dirs crate does this wrong. This was discussed a while ago with an explanation that had to do with the cache dir rather than the config dir. This is something that annoys me (and other macOS users) greatly, as the macOS Library/* dirs are not traditionally used by command-line tools (and especially not by cross-platform command-line tools).

In fact, rustfmt actually uses dirs 2, which puts the macOS config dir as ~/Library/Preferences. This is very wrong, as that folder is intended to be manages by cfprefsd and should only contain serialized preferences configured with the CFPreferences* or NSUserDefaults APIs. This is why dirs v3 changed the config dir to ~/Library/Application Support as that's a better location for app config (it does have a separate preference_dir() which still returns ~/Library/Preferences but nobody should be using that directly, it really only exists to let you find previously-configured files).

My recommendation would be to update dirs to v3 or v4 (I don't know if the v4 breaking change affects rustfmt), then change the relevant code to read from config_dir() first. If there's no config there, then have a #[cfg(any(target_os = "macos", target_os = "ios"))] (or maybe just #[cfg(unix)], checking twice on Linux is harmless) that replicates the ${XDG_CONFIG_HOME:-~/.config}/rustfmt test (note that dirs tests if the env var is an absolute path before using it), and then it can also fall back to checking dirs::preference_dir() as the last check. This might also want the same #[cfg(any(target_os = "macos", target_os = "ios"))] guard too otherwise Linux would end up checking the same location three times in a row.

The end result here is that rustfmt would start looking for ~/Library/Application Support/rustfmt too, which doesn't thrill me but eh, then it would check ~/.config/rustfmt, and then check the old ~/Library/Preferences path.

Or maybe it's better to have the current config_dir() check be skipped on macOS so we don't introduce a check on ~/Library/Application Support/rustfmt.

@bartshin
Copy link

@lilyball
you are my savior finally I can config rustfmt in macOS

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

Successfully merging a pull request may close this issue.

4 participants