Add XDG Support to confy
#119
Conversation
…configs to be stored in xdg defaults
deg4uss3r
force-pushed
the
rth/introduce_xdg
branch
from
0d982cc to
45bfa32
Compare
|
I'll take a look at this tomorrow! Thanks for the PR. |
There was a problem hiding this comment.
Additionally, I'm really uncomfortable with the idea that one would have a silent, seriously breaking change behind a flag that could get accidentally turned on by a dependency. It would be nice if we checked for both locations on macOS, and maybe had a way to select which method should be used by the downstream application (since, for example, GUI apps may want to put their non-user-editable configuration into ~/Library)
| let project; | ||
|
|
||
| #[cfg(not(feature = "xdg"))] | ||
| { |
There was a problem hiding this comment.
It would be nice to have a path for people to upgrade over time; this seems to preclude anyone ever switching, since it doesn't check for both.
There was a problem hiding this comment.
I agree with your points above, I think what I am struggling with a little is how much this library should do versus how much the caller should do.
I do think it is unlikely that the flag would be turned on without the application author knowing. This also isn't destructive, and a config file can be moved by either the application and/or user, so I am bit torn over what the best way to do a migration is.
Maybe that is just making a new function that uses the xdg path, allowing it to still be opt in but less surprising if the feature is enabled.
There was a problem hiding this comment.
To me this crate should not do to much. When I found it, it was just a wrapper over dir/directories/etcetera (choosing the correct one for me) and a choice of data format adapted for configuration.
At firsts it did not even give the config file’s path to the dev or user. I added this function so it is more easy to migrate away from confy, or just let the user know where the file is so they can edit the file with their editor.
I did not use this crate from ages, but if my mind it was the "easy little default crate", and if I wanted a bit more functionality I either build on top, or do manually/find another crate. Like, if:
- I want 2 config file
- I want to change my app name so the config file’s location
- I want to change the data format
In all this cases, it is on me the application dev to find works around. I loved that this crates kept it simple.
Now it may very well evolve to be much more… but I think a new dev should be able to quickly choose between confy and config-rs. (Don’t forget: both are under the rust-cli organization.)
This PR:
directoriescrate in favor ofetceteraxdgwhich addsXDGsupport for Linux and MacOS based on the logic described inetcetera's AppStrategyrustfmtfrom version1.87Resolves #117