Support usage of custom directory
lionel-faber opened this issue · 5 comments
This crate is very useful to get the standard directories for storing files in the app's cache or to read/write configuration files. However, when using this to allow custom directories specified by the user there are some problems.
Let me expand a bit on this. We are building an API that can be used to build applications for different platforms. By default the API expects some configuration files to reside in the application directories that I get using ProjectDirs::from(a, b, c). So far, so good. But I also want to give the user the flexibility of setting a custom path where the configuration files can be stored. So assuming I'm holding this path in memory, I thought I could use ProjectDirs::from. I'm not having a problem with *nix based platforms (Android and iOS included) however on windows /config is being appended to the custom path that has been set. Is there a way to work around this?
TL;DR:
let project_dirs = ProjectDirs::from("/Some/custom/path")?;
println!("{:?}", project_dirs.config_dir());
This prints
/Some/custom/pathon *NIX based platforms (Android and iOS included)/Some/custom/path/configon Windows.
Hey Lionel,
not sure I understand, there is no from that takes a single string – did you have from_path in mind?
Or is this a proposal for adding another method?
Or regarding the fact that Windows has its config/cache/data dirs at the back (unlike e. g. Linux, which has them at the front?)?
Yes sorry. from_path is what I meant.
And as you said, It's regarding the fact that on windows the dirs are the back.
I'm looking to allow developers using my API to call set_config_dir("some/path") and I'd like to be able to use this crate to return that custom path for all *_dir() methods. That way if the custom dir was not set it could default to the directories returned from ProjectDirs::from(a, b, c) instead
The semantics are intentionally designed to protect people from blowing their feet off, by ensuring that the various cache/config/data paths don't end up the same:
The semantics are such that a convenient button somewhere inside the application called "clear cache folder" doesn't nuke all the user's config and data directories too (e. g. even when used for so-called "portable" installs or doing weird RoamingAppData/LocalAppData shenanigans).
On Linux and macOS you get this for free, but on Windows I followed the common approach of splitting the different kinds of files under the application directory.
You could always take the path on Windows you get from from_path as a starting point and change it around to suite your requirements, but please proceed with caution.
I'm staying away as far away as humanely possible from supporting something like this in this library itself, because I'm not going to explain people why e. g. "clearing their cache" killed all their data.
Yes that's understandable. Thanks for the response.
Hope it helped, thanks!