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

Respect XDG_* spec even on macos #76

Open
poliorcetics opened this issue Apr 6, 2022 · 10 comments
Open

Respect XDG_* spec even on macos #76

poliorcetics opened this issue Apr 6, 2022 · 10 comments

Comments

@poliorcetics
Copy link

First, thanks for bacon, I have been trying it out today and its very cool !

bacon --prefs always puts its config file the default path for macOS and in $HOME/.config/bacon/ on Linux. I would for it to respect the XDG_CONFIG_HOME env var on both (especially on macOS), it makes it very easy to then add it to a git repos for dotfiles.

@Canop
Copy link
Owner

Canop commented Apr 6, 2022

As for many Rust projects, I use the directories-next crate to get those directories.

I'd rather not try to code myself this logic or add another fork of the xdg related code.

Can you have a look at this crate to see whether they would be willing to do the change, or accept a PR ?

@poliorcetics
Copy link
Author

I'll ask there, sorry for the noise

@Canop
Copy link
Owner

Canop commented Apr 6, 2022

Sorry I wasn't clear. Your issue is perfectly valid. I'd just prefer you to check there's no solution at the directories-next side before we look for one in bacon.
In the meantime, this issue should stay open. Even if there's a fix in directories-next, we'll have to update the dependency and check it works.

@Canop Canop reopened this Apr 6, 2022
@poliorcetics
Copy link
Author

Related: xdg-rs/dirs#45

@Canop
Copy link
Owner

Canop commented Apr 6, 2022

If there's no progress there, we should probably create a small wrapper crate for directories-next handling that XDG_CONFIG_HOME env var. The name of this crate won't be pretty though, given we're already at "next".

But why has there been no PR already ?

@Stargateur
Copy link
Contributor

Stargateur commented Apr 6, 2022

If there's no progress there, we should probably create a small wrapper crate for directories-next handling that XDG_CONFIG_HOME env var. The name of this crate won't be pretty though, given we're already at "next".

But why has there been no PR already ?

Cause there is no solution, how the lib would decide if it must follow XDG or mac convention on a mac ? They need to decide what to do first. The current behaviour is correct in my eye.

@poliorcetics
Copy link
Author

Cause there is no solution, how the lib would decide if it must follow XDG or mac convention on a mac ?

Another entry point in the API ? Something like a new type, UnixXdg, or a config option acting like a builder .respect_unix_xdg_spec(true) that is defined as fn respect_unix_xdg_spec(self, doit: bool) -> Self ? I'll see about doing a PR this evening if I can

@Stargateur
Copy link
Contributor

An option to force a specific convention feel right.

@poliorcetics
Copy link
Author

Well, my PR on dirs-rs was refused :/

@Stargateur
Copy link
Contributor

Stargateur commented Apr 25, 2022

I was more thinking an option on bacon, bacon would either take the default or use the one the user asked. It would require something like bacon --dirs xdg and a crate that could make it simple to implement like get_xdg_dirs() function

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

3 participants