What causes " error while installing dependencies: {e:?} {}" in windmill-labs/windmill?

Identify the failing dependency from the display name in the message and the `[x] error while installing ` log line, then fix or remove that specific dependency entry

windmill-labs/windmill · error

error while installing dependencies: {e:?} {}

Error message

 error while installing dependencies: {e:?}
{}

What it means

In the per-dependency detached install thread (`try_install_one_detached`), if installing one dependency fails, Windmill logs `[x] error while installing <name>` and records the failure against that dependency, then bails with this message carrying the debug error and the dependency's display name, identifying which single dependency failed.

Source

Thrown at backend/windmill-worker/src/universal_pkg_installer.rs:871

        None,
        false,
        &mut None,
        None,
        None,
    )
    .await
    {
        windmill_queue::append_logs(
            &job_id,
            &w_id,
            format!(
                "\n[x] - error while installing {}: {e:?}",
                &dep.display_name
            ),
            &conn,
        )
        .await;
        bail!(format!(
            "\n error while installing dependencies: {e:?}\n{}",
            &dep.display_name
        ));
    } else {
        if let Some(ref cb) = post_install {
            cb(&dep)?;
        }
        mark_success(dep.path.clone(), &job_id, &w_id).await;
        print_success(
            false,
            true,
            &job_id,
            &w_id,
            &dep.display_name,
            name_ml,
            counter_arc,
            total_to_install,
            start,

View on GitHub (pinned to e474e8803c)

Solutions

Identify the failing dependency from the display name in the message and the `[x] error while installing <name>` log line, then fix or remove that specific dependency entry
Retry the job — installs are per-dependency and transient failures often succeed on retry
Pin a version that actually exists on the configured index for the failing package
If it is a private package, verify worker credentials and index URL

Example fix

# before
some-package==1.2.3
# after (version that exists on the index)
some-package==1.2.4

Defensive patterns

Strategy: retry

Validate before calling

// pre-validate each requirement resolves before submitting the job
// for pkg in $(cat requirements.txt); do pip download --no-deps -q "$pkg" -d /tmp || echo "bad: $pkg"; done

Try / catch

// catch and surface which dep failed
match res {
    Err(e) if e.to_string().contains("error while installing dependencies") => {
        let dep = e.to_string().lines().last().unwrap_or("");
        report_failed_dependency(dep);
    }
    other => other?,
}

Prevention

Resolve the full lockfile locally before deploying to catch bad pins early
Keep dependency lists minimal and pinned
Ensure worker network access/credentials to the package index
Pre-bake flaky dependencies into the worker image

When it happens

Trigger: A single dependency's install in the threaded path fails — bad coordinate, registry unreachable for that package, transient network blip mid-download, or the package no longer existing on the index.

Common situations: One broken pin among many deps in a large requirements list; a package temporarily removed from the index; transient network failure on one download; a rate-limited package registry.

Related errors

AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/4bb3c84c31321eb2. Report an issue: GitHub.