Respect XDG_* spec even on macos

[poliorcetics]

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]

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]

I'll ask there, sorry for the noise

[Canop]

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.

[poliorcetics]

Related: xdg-rs/dirs#45

[Canop]

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]

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]

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]

An option to force a specific convention feel right.

[poliorcetics]

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

[Stargateur]

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

[dsully]

At the very least, bacon should have a --prefs <path> to point at a global config file.

[Canop]

Something easier to do would be to support a BACON_CONFIG env var.

[Canop]

(also, evaluations of alternate crates, eg https://docs.rs/etcetera/latest/etcetera/ are welcome)

[dsully]

(also, evaluations of alternate crates, eg https://docs.rs/etcetera/latest/etcetera/ are welcome)

What would you want the behavior to be on macOS if a ~/Library/Application Support/org.dystroy.bacon/prefs.toml is found?

1. Read it silently
2. Read it, but emit a message noting $XDG_CONFIG_HOME/bacon/prefs.toml can/should be used
3. Move it to $XDG_CONFIG_HOME/bacon/prefs.toml and read it.
4. ??

If both exist, preferring $XDG_CONFIG_HOME/bacon/prefs.toml would make sense IMO.

[Canop]

It looks like we have several locations which makes sense, one of them prefered.

It's compatible with the 2 problems a program have:

• find the config: just search all reasonnable locations
• write a new config: write it at the prefered location

A good API should thus return an ordered set of locations.