What causes "venedored manifests must have packages" in rust-lang/cargo?

Identify the offending crate: run `cargo vendor -v` and look for the last manifest processed before the panic.

venedored manifests must have packages

Error message

venedored manifests must have packages

What it means

Invariant in `prepare_toml_for_vendor`: `me.package.as_mut().expect("venedored manifests must have packages")` (note the source typo "venedored"). Cargo assumes every vendored crate manifest has a `[package]` section. A manifest without `[package]` (a virtual/workspace-only manifest) panics here.

Source

Thrown at src/ops/cargo_vendor.rs:541

        me.manifest_path(),
        me.manifest().is_embedded(),
        gctx,
        &mut warnings,
        &mut errors,
    )?;
    let new_pkg = Package::new(manifest, me.manifest_path());
    Ok(new_pkg)
}

fn prepare_toml_for_vendor(
    mut me: cargo_util_schemas::manifest::TomlManifest,
    packaged_files: &[PathBuf],
    gctx: &GlobalContext,
) -> CargoResult<cargo_util_schemas::manifest::TomlManifest> {
    let package = me
        .package
        .as_mut()
        .expect("venedored manifests must have packages");
    // Validates if build script file is included in package. If not, warn and ignore.
    if let Some(custom_build_scripts) = package.normalized_build().expect("previously normalized") {
        let mut included_scripts = Vec::new();
        for script in custom_build_scripts {
            let path = paths::normalize_path(Path::new(script));
            let included = packaged_files.contains(&path);
            if included {
                let path = path
                    .into_os_string()
                    .into_string()
                    .map_err(|_err| anyhow::format_err!("non-UTF8 `package.build`"))?;
                let path = crate::workspace::parser::normalize_path_string_sep(path);
                included_scripts.push(path);
            } else {
                gctx.shell().warn(format!(
                    "ignoring `package.build` entry `{}` as it is not included in the published package",
                    path.display()
                ))?;

View on GitHub (pinned to 0e07a15537)

Solutions

Identify the offending crate: run `cargo vendor -v` and look for the last manifest processed before the panic.
If it's a git dependency, point `[patch]`/`path` at the specific workspace member with `[package]`, not the virtual root.
Re-fetch the registry index / clear `~/.cargo/registry/cache` in case of a corrupt tarball.
Report upstream if a published `.crate` legitimately lacks `[package]`.

Example fix

// before
let package = me.package.as_mut().expect("venedored manifests must have packages");

// after
let package = me.package.as_mut()
    .ok_or_else(|| anyhow::format_err!(
        "vendored manifest at {:?} is missing [package]; cannot vendor a virtual manifest",
        me.manifest_path))?;

Defensive patterns

Strategy: validation

Validate before calling

// Before vendoring, confirm each dependency manifest has [package].
for dep_manifest in resolved_manifests {
    if dep_manifest.package.is_none() {
        return Err(anyhow!("cannot vendor {}: missing [package]", dep_manifest.manifest_path));
    }
}

Prevention

Point `[patch]`/git deps at the member crate with `[package]`, not a virtual workspace root.
Audit published `.crate` tarballs for `[package]` before indexing a private registry.
Run `cargo fetch` then inspect manifests before `cargo vendor`.

When it happens

Trigger: Running `cargo vendor` when one of the resolved dependency manifests is a virtual manifest (only `[workspace]`, no `[package]`), or when a published `.crate` tarball's `Cargo.toml` is missing `[package]` due to corruption or a malformed registry entry.

Common situations: A dependency published incorrectly without `[package]`; a git dependency whose root `Cargo.toml` is a virtual manifest; a corrupted local registry / vendored cache; a `[patch]` pointing at a workspace root rather than a member crate.

Related errors

AI-assisted analysis of rust-lang/cargo@0e07a15537 (2026-08-06). Data as JSON: /data/errors/fb3d33a0e49f0e79.json. Report an issue: GitHub.