What causes "invalid system package spec '{spec}': expected ' : [@version]'" in jdx/mise?

Remove the extra '@' segment — keep at most one: "brew:postgresql@17" or "brew:postgresql@17.6"

invalid system package spec '{spec}': expected '<manager>:<p

Error message

invalid system package spec '{spec}': expected '<manager>:<package>[@version]'

What it means

parse_use_spec splits a `mise bootstrap packages use` spec of the form `manager:package[@version]` on '@'. After stripping the manager prefix, the remainder must be a package name optionally followed by exactly one '@version'; if a second '@' remains (Some(_) in the match), the spec shape is invalid and this error is raised.

Source

Thrown at src/system/mod.rs:400

                name: rest.to_string(),
                version: None,
                tap_url: None,
                desired: packages::PackageDesiredState::Present,
            },
        ));
    }
    match rest.rsplit_once('@') {
        Some((name, version)) if !name.is_empty() && !version.is_empty() => Ok((
            mgr,
            PackageRequest {
                name: name.to_string(),
                version: (version != "latest").then(|| version.to_string()),
                tap_url: None,
                desired: packages::PackageDesiredState::Present,
            },
        )),
        Some(_) => {
            bail!("invalid system package spec '{spec}': expected '<manager>:<package>[@version]'")
        }
        None => Ok((
            mgr,
            PackageRequest {
                name: rest.to_string(),
                version: None,
                tap_url: None,
                desired: packages::PackageDesiredState::Present,
            },
        )),
    }
}

/// Build [`ManagerPackages`] from already-parsed requests (used by
/// `mise bootstrap packages use`, where version pins come from the CLI spec). Unknown or
/// settings-excluded managers are hard errors.
pub(crate) fn packages_from_requests(
    by_mgr: IndexMap<String, Vec<PackageRequest>>,

View on GitHub (pinned to afd2eddd3a)

Solutions

Remove the extra '@' segment — keep at most one: "brew:postgresql@17" or "brew:postgresql@17.6"
If you want the versioned formula, drop the trailing version: "brew:postgresql@17"
If you want a specific version, drop the '@17' formula suffix from the name and keep one version: "brew:postgresql@17.6"

Example fix

// before
//   mise bootstrap packages use brew:postgresql@17@latest
// after
//   mise bootstrap packages use brew:postgresql@17

Defensive patterns

Strategy: validation

Validate before calling

// A use-spec is manager:package with at most one '@version':
function isValidUseSpec(spec: string): boolean {
  const colon = spec.indexOf(":");
  if (colon <= 0 || colon === spec.length - 1) return false;
  const pkgPart = spec.slice(colon + 1);
  return pkgPart.split("@").length <= 2;
}
// isValidUseSpec("brew:postgresql@17") === true
// isValidUseSpec("brew:postgresql@17@latest") === false

Type guard

function hasAtMostOneVersion(s: string): boolean {
  const pkg = s.slice(s.indexOf(":") + 1);
  return pkg.split("@").length <= 2;
}

Try / catch

try {
  await mise(["bootstrap", "packages", "use", spec]);
} catch (e) {
  if (String(e).includes("<manager>:<package>[@version]")) {
    throw new Error(`Spec "${spec}" has multiple '@' segments; use at most one version`);
  }
  throw e;
}

Prevention

Never combine a versioned formula name with an explicit version (postgresql@17@latest is invalid)
Count the '@' characters after the manager prefix — at most one is allowed
Don't paste package filenames or image tags containing '@' directly
Pick either the formula variant (@17) or a concrete version (@17.6), not both

When it happens

Trigger: Calling parse_use_spec (directly or via `mise bootstrap packages use`) with more than one '@' in the package part, e.g. "brew:openssl@3@latest" or "apt:curl@8.5.0-1ubuntu2@foo".

Common situations: Pasting a fully-qualified package filename or docker-style tag containing '@'; double-appending a version to an already-versioned formula name like brew:postgresql@17@latest (versioned formula + explicit version must not be combined this way).

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/8d14f31d1ac3d838. Report an issue: GitHub.