jdx/mise · error

unrecognized install {s:?} in lockfile

Error message

unrecognized install {s:?} in lockfile

What it means

When parsing mise.lock, a platform entry's optional install field only accepts the string "source" (marking a from-source build); any other string aborts parsing of the whole lockfile (src/lockfile.rs:549-553). This is a forward-compatibility guard: the value was written by a newer format than this build understands.

Source

Thrown at src/lockfile.rs:550

                merge_additional_artifacts(&self.additional_artifacts, &other.additional_artifacts)
            },
        }
    }
}

impl TryFrom<toml::Value> for PlatformInfo {
    type Error = Report;
    fn try_from(value: toml::Value) -> Result<Self> {
        match value {
            toml::Value::String(checksum) => Ok(PlatformInfo {
                checksum: Some(checksum),
                ..Default::default()
            }),
            toml::Value::Table(mut t) => {
                let install = match t.remove("install") {
                    Some(toml::Value::String(s)) if s == "source" => Some(s),
                    Some(toml::Value::String(s)) => {
                        bail!("unrecognized install {s:?} in lockfile")
                    }
                    _ => None,
                };
                let checksum = match t.remove("checksum") {
                    Some(toml::Value::String(s)) => Some(s),
                    _ => None,
                };
                let size = t
                    .remove("size")
                    .and_then(|v| v.as_integer())
                    .map(|i| i.try_into())
                    .transpose()?;
                let url = match t.remove("url") {
                    Some(toml::Value::String(s)) => Some(s),
                    _ => None,
                };
                let url_api = match t.remove("url_api") {
                    Some(toml::Value::String(s)) => Some(s),

View on GitHub (pinned to 6f52dcdf99)

Solutions

1. Upgrade mise on the failing machine (mise upgrade) to at least the version that wrote the lockfile.
2. Or regenerate the lockfile with the installed version: rm mise.lock && mise lock.
3. Pin one mise version for the whole team ([tools] mise = "x.y.z" in mise.toml) so lockfile writer and readers never diverge.
4. Revert any hand edits — mise.lock is generated output.

Example fix

# before: older mise reading a newer lockfile
$ mise install
ERROR unrecognized install "binary" in lockfile

# after
$ mise upgrade && mise install   # the reader now understands the format

# CI guard: refuse install kinds this mise cannot parse before it fails mid-job
grep -P 'install\s*=\s*"(?!source")' mise.lock && { echo 'mise.lock has an install kind this mise rejects — upgrade mise or re-lock'; exit 1; } || true

Catch lockfile parse errors during mise install/mise lock and fail fast with an actionable message: upgrade mise to the lockfile writer's version, or delete mise.lock and re-lock. Do not auto-regenerate silently — that drops the pinned-version guarantees the lockfile exists for.

When it happens

Trigger: Reading a mise.lock whose [tools.<name>...] platform table has install = "<anything but source>" — typically a lockfile written by a newer mise release that added a new install kind, opened by a machine or CI image running an older mise.

Common situations: Teammates or CI lanes on different mise versions after someone upgrades and commits a refreshed mise.lock; pinned older mise in Docker images consuming newer lockfiles; hand-edited lockfiles.

Related errors

• unrecognized github_attestations status {s:?} in lockfile
• unrecognized provenance table format in lockfile: {:?}
• additional_artifacts must be an array in lockfile
• unsupported asset info format
• unsupported conda package info format

AI-assisted analysis of jdx/mise@6f52dcdf99 (2026-08-22). Data as JSON: /api/errors/e62f08551e1b916d. Report an issue: GitHub.