pub trait Pather: Send + Sync {
Show 18 methods
// Required methods
fn home_dir(&self) -> &Path;
fn dotfiles_root(&self) -> &Path;
fn data_dir(&self) -> &Path;
fn config_dir(&self) -> &Path;
fn cache_dir(&self) -> &Path;
fn xdg_config_home(&self) -> &Path;
fn app_support_dir(&self) -> &Path;
fn shell_dir(&self) -> &Path;
// Provided methods
fn pack_path(&self, pack: &str) -> PathBuf { ... }
fn pack_data_dir(&self, pack: &str) -> PathBuf { ... }
fn handler_data_dir(&self, pack: &str, handler: &str) -> PathBuf { ... }
fn log_dir(&self) -> PathBuf { ... }
fn init_script_path(&self) -> PathBuf { ... }
fn deployment_map_path(&self) -> PathBuf { ... }
fn last_up_path(&self) -> PathBuf { ... }
fn probes_shell_init_dir(&self) -> PathBuf { ... }
fn probes_brew_cache_dir(&self) -> PathBuf { ... }
fn prompts_path(&self) -> PathBuf { ... }
}Expand description
Provides all path calculations for dodot.
Every path that dodot uses — XDG directories, pack locations,
handler data directories — is computed through this trait. This
keeps path logic centralised and makes testing straightforward:
construct a Pather whose directories all live under a temp dir.
Use &dyn Pather (trait objects) throughout the codebase.
Required Methods§
Sourcefn dotfiles_root(&self) -> &Path
fn dotfiles_root(&self) -> &Path
Root of the dotfiles repository.
Sourcefn config_dir(&self) -> &Path
fn config_dir(&self) -> &Path
XDG config directory for dodot (e.g. ~/.config/dodot).
Sourcefn xdg_config_home(&self) -> &Path
fn xdg_config_home(&self) -> &Path
XDG config home (e.g. ~/.config). Used by symlink handler
for subdirectory target mapping.
Sourcefn app_support_dir(&self) -> &Path
fn app_support_dir(&self) -> &Path
Application-support root, the third filesystem coordinate the symlink resolver understands.
On macOS this resolves to $HOME/Library/Application Support by
default, the canonical home for GUI app config. On Linux and
other platforms it resolves to xdg_config_home() so the _app/
prefix and app_aliases route through ~/.config —
indistinguishable from _xdg/ on those platforms but the
mechanism stays platform-agnostic.
The OS check lives only in XdgPatherBuilder::build; the
resolver operates on textual prefixes alone. See
docs/proposals/macos-paths.lex §2.1.
Provided Methods§
Sourcefn pack_data_dir(&self, pack: &str) -> PathBuf
fn pack_data_dir(&self, pack: &str) -> PathBuf
Data directory for a specific pack (e.g. .../data/packs/{pack}).
Sourcefn handler_data_dir(&self, pack: &str, handler: &str) -> PathBuf
fn handler_data_dir(&self, pack: &str, handler: &str) -> PathBuf
Data directory for a specific handler within a pack
(e.g. .../data/packs/{pack}/{handler}).
Sourcefn init_script_path(&self) -> PathBuf
fn init_script_path(&self) -> PathBuf
Path to the generated shell init script.
Sourcefn deployment_map_path(&self) -> PathBuf
fn deployment_map_path(&self) -> PathBuf
Path to the deployment map TSV, overwritten on every up / down.
See docs/proposals/profiling.lex §3.2.
Sourcefn last_up_path(&self) -> PathBuf
fn last_up_path(&self) -> PathBuf
Path to a single-line file recording the unix timestamp of the
most recent successful dodot up. Used by dodot probe shell-init to flag profiles captured before that up as stale.
Absent until the first up runs.
Sourcefn probes_shell_init_dir(&self) -> PathBuf
fn probes_shell_init_dir(&self) -> PathBuf
Directory where shell-init profile reports are written, one TSV
per shell start. See docs/proposals/profiling.lex §3.1.
Sourcefn probes_brew_cache_dir(&self) -> PathBuf
fn probes_brew_cache_dir(&self) -> PathBuf
On-disk cache for homebrew-cask probe data. One JSON file per
cask token; TTL-based invalidation. See
docs/proposals/macos-paths.lex §8.2.
Lives under cache_dir (not data_dir) because the contents are
rederivable — losing them is fine, the next probe re-runs brew info. Co-located with future probe caches under probes/.
Sourcefn prompts_path(&self) -> PathBuf
fn prompts_path(&self) -> PathBuf
Persistent record of prompts the user has dismissed (e.g.
onboarding hints, install offers). Content-agnostic: callers
pass opaque keys, the registry just tracks dismissed/active.
Lives under data_dir (not cache_dir) because losing it
would re-prompt the user — preference state, not cache.