run-llama/liteparse · error
USERPROFILE env var not set
Error message
USERPROFILE env var not set
What it means
In pdfium-sys's build script, dirs_cache determines the cache directory per-platform. On Windows it prefers LOCALAPPDATA but falls back to USERPROFILE; if neither environment variable is set, the .expect on USERPROFILE panics with this message. The build script cannot locate a per-user cache directory for the downloaded pdfium library.
Solutions
- Set USERPROFILE (e.g. USERPROFILE=C:\Users\builduser) in the build environment.
- Set LOCALAPPDATA instead — it is checked first and short-circuits the USERPROFILE lookup.
- Pre-populate the pdfium cache directory so the download path (and dirs_cache) is avoided, e.g. via the crate's cache-dir override if available.
- In CI, use a runner image that initializes the standard Windows user environment.
Example fix
// before: stripped CI step
- run: cargo build
// after: ensure env vars exist
- run: |
echo "USERPROFILE=$USERPROFILE"
cargo build
env:
USERPROFILE: C:\Users\runneradmin
LOCALAPPDATA: C:\Users\runneradmin\AppData\Local Defensive patterns
Strategy: validation
Validate before calling
// CI preflight (PowerShell): fail fast if env is missing
if (-not $env:LOCALAPPDATA -and -not $env:USERPROFILE) {
throw "Set USERPROFILE or LOCALAPPDATA before building"
} Prevention
- Set USERPROFILE/LOCALAPPDATA explicitly in Windows CI containers
- Add an env sanity check as the first CI step
- Avoid sanitizing the environment when invoking cargo
When it happens
Trigger: Running `cargo build` of a workspace depending on pdfium-sys on Windows inside an environment where both LOCALAPPDATA and USERPROFILE are unset — e.g. a stripped-down CI container, a service account with a minimal environment, or a custom build runner.
Common situations: Windows CI runners (Docker executors, GitHub Actions containers) that don't provision standard user env vars; build tools that sanitize the environment; running cargo under a Windows service account with no user profile.
Understand the failure class
Background: "environment variable is not set" and "Missing keys in environment" errors: what missing required env var messages mean and how to fix them — this error's family across 28 libraries.
Related errors
- HOME env var not set
- failed to create temp dir
- failed to extract pdfium archive
- failed to move pdfium to cache dir
- WASI proc_exit called with code
AI-assisted analysis of run-llama/liteparse@22d2dd8cd7 (2026-09-08).
Data as JSON: /api/errors/620e5534c0ef0244.
Report an issue: GitHub.
Appendix: source
Thrown at crates/pdfium-sys/build.rs:134
let base = dirs_cache().join("pdfium-rs");
let tag_safe = PDFIUM_RELEASE_TAG.replace('/', "_");
let asset = pdfium_asset_stem();
base.join(tag_safe).join(asset)
}
fn dirs_cache() -> PathBuf {
if let Ok(xdg) = env::var("XDG_CACHE_HOME") {
return PathBuf::from(xdg);
}
let target_os = env::var("CARGO_CFG_TARGET_OS").unwrap_or_default();
// Windows -> USERPROFILE
if target_os == "windows" {
if let Ok(local_app_data) = env::var("LOCALAPPDATA") {
return PathBuf::from(local_app_data);
}
let home = env::var("USERPROFILE").expect("USERPROFILE env var not set");
return PathBuf::from(home).join("AppData\\Local");
}
let home = env::var("HOME").expect("HOME env var not set");
if target_os == "macos" {
PathBuf::from(&home).join("Library/Caches")
} else {
PathBuf::from(&home).join(".cache")
}
}
/// Map target triple to the pdfium-binaries asset name (without .tgz).
fn pdfium_asset_stem() -> &'static str {
let target = env::var("TARGET").unwrap();
match target.as_str() {
"aarch64-apple-darwin" => "pdfium-mac-arm64",
"x86_64-apple-darwin" => "pdfium-mac-x64",
// Universal macOS binary works for both, but we prefer arch-specificView on GitHub (pinned to 22d2dd8cd7)