Provide Path trait for application granting access to common user directories

[mainrs]

I am thinking about a trait like this:

pub trait ProgramPaths {
    fn config_dir(&self) -> &AbsPath;
    fn data_dir(&self) -> &AbsPath;
}

This would give CLIs access to the preferred user's configuration directory as well as their data directory. A crate like https://crates.io/crates/directories could be used.

If interest exists, I'd be happy to open a PR merging such a trait. Maybe putting this behind a feature called "directories" or "project-dirs" or similar.

[simonsan]

I think that is a good idea. In general, I feel, configuration management is a bit cumbersome right now. Especially, if you want to have more than on config file being used for different purposed or merging values from different inputs (ENV, cli + config file). For the trait design, I'm not quite sure, though. It might be worthwhile to add something non-breaking to the Application Trait?

[mainrs]

My idea was to extend the application traits path type py appending + ProgramPaths to it's bounds. I think this is a non breaking change? I'm not sure though

[tony-iqlusion]

The Application::Paths associated type already exists, so that's what you should build on: https://docs.rs/abscissa/latest/abscissa/prelude/trait.Application.html#associatedtype.Paths

I would definitely prefer not to pull in directories by default: it has a whopping 60 (transitive) dependencies to accomplish what feels like a relatively mundane bit of functionality, but I think it would be fine to find a way to compose with it easily and perhaps give some examples.

[tony-iqlusion]

Especially, if you want to have more than on config file being used for different purposed or merging values from different inputs (ENV, cli + config file).

@simonsan please open separate issues for this as they're off topic for this one, and also note that overriding configuration with CLI arguments is what the config::Override trait is for.

[mainrs]

I would definitely prefer not to pull in directories by default [...]

I can made this feature optional, no problem! I'm curious how you came up with the 60 transitive dependencies though. It should have three major ones: libc, option-ext and windows-sys, all pulled in by directories-sys. redox_users does not matter, since we can disable that feature. I don't think abscissa works on redox anyway 🤔

[tony-iqlusion]

@mainrs the dependency tree is as follows:

directories 5.0.1
└── dirs-sys 0.4.1
    ├── windows-sys 0.48.0
    │   └── windows-targets 0.48.5
    │       ├── windows_x86_64_msvc 0.48.5
    │       ├── windows_x86_64_gnullvm 0.48.5
    │       ├── windows_x86_64_gnu 0.48.5
    │       ├── windows_i686_msvc 0.48.5
    │       ├── windows_i686_gnu 0.48.5
    │       ├── windows_aarch64_msvc 0.48.5
    │       └── windows_aarch64_gnullvm 0.48.5
    ├── redox_users 0.4.4
    │   ├── thiserror 1.0.57
    │   │   └── thiserror-impl 1.0.57
    │   │       ├── syn 2.0.48
    │   │       │   ├── unicode-ident 1.0.12
    │   │       │   ├── quote 1.0.35
    │   │       │   │   └── proc-macro2 1.0.78
    │   │       │   │       └── unicode-ident 1.0.12
    │   │       │   └── proc-macro2 1.0.78
    │   │       ├── quote 1.0.35
    │   │       └── proc-macro2 1.0.78
    │   ├── libredox 0.0.1
    │   │   ├── redox_syscall 0.4.1
    │   │   │   └── bitflags 1.3.2
    │   │   ├── libc 0.2.153
    │   │   └── bitflags 2.4.2
    │   └── getrandom 0.2.12
    │       ├── wasi 0.11.0+wasi-snapshot-preview1
    │       ├── libc 0.2.153
    │       └── cfg-if 1.0.0
    ├── option-ext 0.2.0
    └── libc 0.2.153

All of those do matter and impact the Cargo.lock resolution, even if the platform specific ones are the only ones that are actually compiled.

There is unfortunately no way to feature-gate redox support and all of the crates will wind up in Cargo.lock regardless.