pub fn config_dir() -> Result<Utf8PathBuf, ConfigDirError>Expand description
Config-directory resolution: XDG_CONFIG_HOME, then APPDATA
(Windows), then $HOME/.config.
The single source of truth. This existed as two hand-maintained
copies — doiget-cli::commands::fetch::config_dir_utf8 and
doiget-mcp::config_dir_utf8 — whose own doc comment warned that
divergence “would silently desync the user-extension allowlist
surfaces”. They had already diverged: the CLI copy accepted
XDG_CONFIG_HOME="" and resolved a relative doiget/config.toml
under the cwd, while the MCP copy treated blank as unset. Blank-is-
unset is the answer kept here, because a relative config path is a
silent wrong answer of exactly the #441 / #504 kind.
It lives in doiget-core because the fetch path needs it: with the
resolver one crate up, orchestrator could not read config.toml at
all, so every file-based setting had to be re-implemented in the CLI
or go unread. [network] unpaywall_email went unread for four
releases for that reason (#504).
No dirs dependency — every new dep adds cargo-vet exemption churn,
and expand_store_root below already reads HOME directly.
§Errors
ConfigDirError::NotUnicode if a consulted variable is set to a
non-UTF-8 value; ConfigDirError::NoHome if none is set.