feat(env): Make rustic more portable

[simonsan]

To make rustic more portable, we can use RUSTIC_HOME to locate the user's wanted config directories without relying on conventional/standard directories varying on the operating system. On Windows, we add another layer to get compatibility paths (e.g. in the USERPROFILE).

Fixes #859

[aawsome]

Why not simply add two entries

std::env::var_os("USERPROFILE").map(|path| {
PathBuf::from(path).join(r".config\rustic")),
std::env::var_os("USERPROFILE").map(|path| {
PathBuf::from(path).join(r".rustic")),

here? If this seems to heavy, create 2 functions which return these results.

[simonsan]

Sorry, I don't understand. Instead of what should we do that, you marked get_home_config_path(),?

[simonsan]

Do you mean like that:

    let mut paths = vec![
        get_home_config_path(),
        ProjectDirs::from("", "", "rustic")
            .map(|project_dirs| project_dirs.config_dir().to_path_buf()),
        get_global_config_path(),
        Some(PathBuf::from(".")),
        #[cfg(target_os = "windows")]
        std::env::var_os("USERPROFILE").map(|path| PathBuf::from(path).join(r".config\rustic")),
        #[cfg(target_os = "windows")]
        std::env::var_os("USERPROFILE").map(|path| PathBuf::from(path).join(".rustic")),
    ];

[simonsan]

If that was the idea, I found it a bit cleaner, although we need to have all that lint deactivated and mutable variable, to have that in its own function. Just because, we can have access to that, to just get the config paths singly, when we need them.

For example, this:

fn get_config_paths(filename: &str) -> Vec<PathBuf> {
    vec![
        std::env::var_os("RUSTIC_HOME").map(|home_dir| PathBuf::from(home_dir).join("config")),
        ProjectDirs::from("", "", "rustic")
            .map(|project_dirs| project_dirs.config_dir().to_path_buf()),
        get_global_config_path(),
        Some(PathBuf::from(".")),
        #[cfg(target_os = "windows")]
        std::env::var_os("USERPROFILE").map(|path| PathBuf::from(path).join(r".config\rustic")),
        #[cfg(target_os = "windows")]
        std::env::var_os("USERPROFILE").map(|path| PathBuf::from(path).join(".rustic")),
    ]
    .into_iter()
    .filter_map(|path| path.map(|p| p.join(filename)))
    .collect::<Vec<_>>()
}

would work, but would not let us have RUSTIC_HOME access in a function, if we just need it for something else, e.g. opening a pdf in that folder, when we would want to open documentation or anything else in the home folder. Also I feel it makes it a bit 'chaotic' somehow, at least from reading it, but this may be personal preference.

Hence I think extracting these things into their own functions is better long-term.

[aawsome]

Yes, then simply use get_userprofile_config_rustic() and get_userprofile_rustic() or something like this.

[simonsan]

Thinking about it, all those directories are a bit different:

RUSTIC_HOME: we use RUSTIC_HOME/config here for the configs, RUSTIC_HOME/logs I reserved on scoop for log files
USERPROFILE\.config\rustic: we use a root directory here for the configs
USERPROFILE\.rustic: same here, we use a root directory

I think consistency is important in that regard, so people can for example use their rustic-package unpack it, change some configs and start. Which would mean, that we would need config/ as a subdirectory in each of these, although it doesn't make a lot of sense in
USERPROFILE\.config\rustic to have another subdir for config. But then, we also can't use this directory as a kind of HOME directory, where for example also log files would be found and other resources. 🤔

[simonsan]

Application::Path with RusticPaths seems like the cleaner solution, so we have search paths easily accessible. Closing this here in favour of #1342