fix(chezmoi): seed data.xdg at init so first apply works on fresh hosts#14
Merged
Conversation
dot_config/chezmoi/private_chezmoi.toml.tmpl is a managed file, not an init template — on a clean host, it can't populate its own config before apply, so any template that reads .xdg.* (e.g. wgetrc.tmpl) fails with "map has no entry for key \"xdg\"". Adding a source-root .chezmoi.toml.tmpl makes chezmoi init render the config before the first apply. Values fall back to XDG-spec defaults under $HOME when env vars are unset, so it works on macOS and Linux alike. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a source-root
.chezmoi.toml.tmplthat seedsdata.xdg.{cache,config,data,state}atchezmoi inittime, before the firstapplyruns. This unblocks templates that reference.xdg.*on a fresh host.Why
dot_config/chezmoi/private_chezmoi.toml.tmplalready defines[data.xdg], but it's a managed file — it only exists after the firstapply. Templates that depend on.xdg.*(currentlydot_config/wget/wgetrc.tmpl:1, via{{ .xdg.cache }}) fail on a brand-new machine because the data key isn't populated yet. Classic bootstrap ordering problem: the config that produces the data is itself produced by the thing that needs the data.Chezmoi resolves this via the source-root
.chezmoi.toml.tmpl, which it renders to~/.config/chezmoi/chezmoi.tomlduringinit— before anyapply.Design notes
The init template is narrow by design: it only seeds
[data.xdg].[diff]and[merge]stay in the managedprivate_chezmoi.toml.tmpl, which overwrites the init output on the first apply. Rationale: keep the init template limited to what init must provide; let the managed file own everything else so there's a single source of truth post-bootstrap.For cross-platform behavior,
env "XDG_*" | default (joinPath .chezmoi.homeDir ...)respectsXDG_*when exported (Linux, or macOS users who set them), otherwise falls back to XDG-spec defaults under\$HOME. This differs from the managed template, which assumesXDG_*is set; the init template can't assume that on a fresh host.One divergence risk worth calling out: the two templates now both define
[data.xdg]with slightly different logic (init has fallbacks, managed does not). IfXDG_*is unset at apply time, the managed file will write empty strings and break.xdg.*consumers. Worth a follow-up to unify them — either by giving the managed template the same fallback, or by sourcingXDG_*defaults earlier in the shell env.