Tracking Issue for `xdg_basedir`

[CAD97]

View all comments

Feature gate: #![feature(xdg_basedir)]

This is a tracking issue for API providing the XDG Base Directories in std::os::unix::xdg.

• Superseded by Add std::fs::{Home|Media}Dirs #158936

Public API

// in std::os::unix::xdg (new module)

pub fn data_home_dir() -> PathBuf;
pub fn config_home_dir() -> PathBuf;
pub fn state_home_dir() -> PathBuf;
pub fn cache_home_dir() -> PathBuf;

#[derive(Debug, Clone)]
pub struct XdgDirsIter { /* ... */ };
impl Iterator for XdgDirsIter { /* ... */ }

pub fn data_dirs() -> XdgDirsIter;
pub fn config_dirs() -> XdgDirsIter;

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: ACP: Add XDG Basedirs API to std::os::unix::xdg libs-team#805
• Implementation: Add xdg_basedir API #157518
• Superseded by Add std::fs::{Home|Media}Dirs #158936

Unresolved Questions

• Should we provide runtime_dir (doesn't have a specified default) and/or bin_home_dir (has a specified default but the environment variable override is a common non-XDG-standard extension)?

[joboet]

I do not think this is a good idea. Putting this API into the shared UNIX module does not make any sense to me, because platforms like macOS are never going to follow the XDG specification, making this API entirely useless there. In general, std should not provide an API for something that is distribution- (and not target-)specific, and even then – is the target audience for this really large enough? We don't provide APIs for console colours or similar things either, not because they're not useful, but because it's out of scope.

@rustbot label +I-libs-api-nominated
(as this was unilaterally approved by @BurntSushi)

[ChrisDenton]

macOS are never going to follow the XDG specification

For bash and cli tools (git, docker, etc)? I think there is a lot of precedent there. The story is different for GUI apps of course but that doesn't mean it's never used.

[joboet]

Well, half the CLI tools do use the Linux paths, but the other half doesn't. And the "proper" (in the sense that idiomatic applications use them) directories are not the XDG ones. See e.g. the platform_dirs library which hardcodes the macOS directories. I don't think std should pick a side here.

[ChrisDenton]

It needn't pick a side. It could also have macos specific methods for Library/Caches and Library/Application Support.

[BurntSushi]

FWIW, I approved the ACP knowing full well that there is some design work to figure out in terms of how to deal with macOS here. There are multiple ways of handling it, and I expect std to have something to say about that somewhere as part of this work. Indeed, std needn't pick a side, and should empower stakeholders (people who ship software to end users) to make the choice that best suits their needs. Moreover, the presence of an XDG implementation in std needn't be prescriptive itself. For example, some stakeholders may continue to elect to put dotfiles directly in $HOME and ignore XDG altogether.

[joboet]

That's a reasonable stance, but I think you could argue that std having this API at all is picking a side. I can well imagine someone going "where should my cache files go", then seeing cache_home_dir and not thinking twice about whether this is actually a good choice (which I don't think it is on macOS).

[CAD97]

I do think it's a reasonable ask to have macOS's APIs available as well before stabilizing XDG paths in a location available to macOS, to avoid accidentally implying XDG as the only convention available.

[tgross35]

It feels weird excluding Windows but including MacOS, since (as mentioned) CLI tools on both of those platforms often use XDG paths. Could we just always provide them in std::env::xdg?

We could have separate modules at std::os::{linux,darwin,windows}::base_directories for the OS-specific directories with an API that fits.

[ChrisDenton]

For Windows, directly using XDG base directories is much less common (though does happen with some ported tools) and Windows isn't a Unix so some things make no sense at all if going by the spec (e.g. XDG_DATA_DIRS and XDG_CONFIG_DIRS).

That said, I would support having Windows specific functions that return APPDATA and LOCALAPPDATA. We could document XDG equivalents. Something like:

Windows	XDG equivelent
APPDATA	XDG_CONFIG_HOME XDG_STATE_HOME
LOCALAPPDATA	XDG_DATA_HOME XDG_CACHE_HOME

[programmerjake]

on Android, XDG isn't usually a thing, but it is under Termux (a terminal emulator app that has a custom Linux distro that runs out of /data/data/com.termux/files/, e.g. HOME=/data/data/com.termux/files/home)

[orlp]

I concur with @joboet and don't think this should be added, I've expanded my thoughts on the ACP: rust-lang/libs-team#805 (comment).

I also don't know why the ACP was accepted unilaterally.