windmill-labs/windmill · error

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

Error message

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

What it means

When installing a script's language dependencies in batch (`par_install_language_dependencies_all_at_once`), Windmill captures the installer's combined output into a buffer. If the install subprocess errors, the job fails with this message containing the debug-formatted error followed by that buffered output, showing what the package manager actually printed.

Source

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

            conn,
            // TODO: Return mem_peak
            &mut 0,
            // TODO: Return canceld_by_ref
            &mut None,
            child,
            is_sandboxing_enabled(),
            &worker_name,
            &w_id,
            &installer_executable_name,
            None,
            false,
            &mut None,
            pipe_stdout,
            None,
        )
        .await
        {
            bail!(format!(
                "\nerror while installing dependencies: {e:?}\n{}",
                buf
            ));
        }
        {
            postinstall_cb(for_all_at_once_copy.clone()).await?;
        }
        for RequiredDependency { path, _s3_handle, .. } in for_all_at_once_copy.into_iter() {
            mark_success(path.clone(), job_id, w_id).await;
            #[cfg(all(feature = "enterprise", feature = "parquet"))]
            {
                if let Some(os) = windmill_object_store::get_object_store().await {
                    let language_name = _language_name.to_owned();
                    tokio::spawn(async move {
                        if let Err(e) = crate::global_cache::build_tar_and_push(
                            os,
                            path,
                            language_name,

View on GitHub (pinned to e474e8803c)

Solutions

  1. Read the buffered installer output after `{e:?}` in the message — it contains the package manager's actual failure (conflict, 404, etc.) — and fix the dependency list accordingly
  2. Resolve version conflicts by pinning compatible versions or loosening constraints in requirements/lockfile
  3. Verify the package index (PyPI or private mirror) is reachable and authenticated from the worker; fix index URL/credentials
  4. Retry the job after fixing — the failure is not cached as success

Example fix

# before (requirements)
requests==2.20.0
urllib3>=2.0
# after (compatible pins)
requests==2.31.0
urllib3>=2.0,<3
Defensive patterns

Strategy: retry

Validate before calling

// pre-check that requirements resolve with the same resolver before deploying
// uv pip compile requirements.txt > /dev/null && echo resolvable

Try / catch

// wrapper around job submission
let res = run_job(...).await;
if let Err(e) = &res {
    if let Some(out) = extract_installer_output(&e.to_string()) {
        log::error!("dependency install output: {out}");
    }
}

Prevention

When it happens

Trigger: A batch dependency install for any language fails — resolver conflicts, unreachable package index, missing system build deps, an invalid requirement line, or the install command exiting non-zero with output captured in `buf`.

Common situations: Conflicting pinned versions in requirements; private index unreachable or mis-authenticated from the worker; a package requiring compilation without build tools; a typo'd package name in requirements.txt.

Related errors


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