Open thelink2012 opened 9 years ago
We'd probably need to prototype this in an external crate first. Doing this in a cross-platform manner will be very difficult.
Linux (the XDG spec actually) defines:
$XDG_CACHE_HOME
: cache$XDG_DATA_HOME
: application "data"$XDG_CONFIG_HOME
: application "config"$XDG_RUNTIME_DIR
: session-specific temporary files (sockets etc...)Windows defines:
%AppData
: Any cache, data, config that can be safely synced between computers.%LocalAppData
: Any cache, data, config that can't be safely synced between computers.I have no idea what OSX uses but to cover Windows and Linux alone, we'd need we'd probably want at least the following functions (with better names):
cache_dir
(always local)local_data_dir
local_config_dir
data_dir
config_dir
Even then, this wouldn't support $XDG_RUNTIME_DIR
because there is no equivalent under Windows.
(I'm not saying we shouldn't try to do this, just that this is a really hard (if not impossible) problem.)
Agreed that this should first go into an external crate to percolate for a while. After we're pretty damn sure that all the paths make sense, then move it into std.
Maybe we can steal the glib design of these sort of functions since they presumably have some amount of portability nailed down.
@ben0x539 not really. Those methods don't distinguish between roaming versus local. Also, their user cache dir for windows is out of date; Microsoft now suggests using per-application cache directories.
Excluding the runtime dir, this Python module has a fairly complete list of where things should be on each platform and is useful for reference: https://github.com/ActiveState/appdirs/blob/master/appdirs.py
I was also looking for this, and came across https://docs.rs/app_dirs/. It's the best example of an existing crate that I've found so far.
Currently there is only a way to easily store application specific data using the standard library,
std::env::home_dir
. That's not a quite correct way. I was thinking about the addition of astd::env::appdata_dir
function?The home directory is only suitable for storing application data on Linux (and perhaps other *nixes?), on Windows the correct place is
%AppData%
or%LocalAppData%
and on OSX it seems to be~/Library/Preferences/
or~/Library/Application Support/
.That brought my attention when I noticed that Cargo stores it's data on
%USERPROFILE%/.cargo/
_(std::env::home_dir
gives%USERPROFILE
on Windows)_, note how directories starting with.
aren't hidden on Windows and those pollute the user profile directory.However I have a few concerns about this myself:
std::env
should have functions that aren't directly a enviroment variable (e.g.~/Library/...
) though it saysand various other important directories
on it's description.