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

  1. Set USERPROFILE (e.g. USERPROFILE=C:\Users\builduser) in the build environment.
  2. Set LOCALAPPDATA instead — it is checked first and short-circuits the USERPROFILE lookup.
  3. 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.
  4. 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

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


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-specific

View on GitHub (pinned to 22d2dd8cd7)