What causes "unsupported Python lock project settings" in jdx/mise?

Regenerate the lock with mise so it emits the canonical single 4-key project table: `mise lock --bump `.

unsupported Python lock project settings

Error message

unsupported Python lock project settings

What it means

As a final guard, validate_uv_lock whitelists lockfile structure: exactly one [project] table and exactly four keys in it (dependencies, name, requires-python, and one more as produced by mise). Any extra project settings or build-system configuration in the lock is treated as untrusted/unsupported and rejected, since arbitrary project settings from a lockfile are never honored.

Solutions

Regenerate the lock with mise so it emits the canonical single 4-key project table: `mise lock --bump <tool>`.
Remove unsupported keys/tables ([build-system], extra [project] entries) from mise.lock — or better, re-lock instead of editing.
Use mise of a compatible version so the lock schema matches what the validator expects.
If you need custom project/build settings, do it in the package's own project, not in mise's synthetic lock project.

Example fix

// before (mise.lock, extra section)
[project]
name = "mise-pypi-tool-environment"
dependencies = ["ruff==0.9"]
requires-python = ">=3.8"

[build-system]
requires = ["setuptools"]

// after: remove extras or regenerate
$ mise lock --bump <tool>

Defensive patterns

Strategy: validation

Validate before calling

// sanity-check lock structure before install
if (lock.project.length !== 1 || Object.keys(lock.project[0]).length !== 4) run('mise lock --bump <tool>');

Prevention

Never merge or post-process mise.lock with external tooling
Don't copy a project uv.lock into mise.lock
Regenerate locks with mise instead of editing structure

When it happens

Trigger: Thrown from validate_uv_lock when `lock.project.len() != 1` (multiple [project] tables) or the project table's key count != 4 — i.e. the lock contains extra settings or a build system block; via prepare_install_version, resolve_uv_lock, install_uv_lock.

Common situations: The mise.lock was produced or merged by other tooling that added [build-system] or extra [project] keys; hand-edits added settings; an older/newer lock schema version; a lock copied from a real project's uv.lock instead of mise-generated one.

Related errors

AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17). Data as JSON: /api/errors/0f2d29979d7799c0. Report an issue: GitHub.

Appendix: source

Thrown at src/backend/pipx/lock.rs:426

                })?;
            for wheel in wheels {
                let hash = wheel
                    .get("hash")
                    .and_then(toml::Value::as_str)
                    .and_then(|h| h.strip_prefix("sha256:"));
                if !hash.is_some_and(|h| h.len() == 64 && h.bytes().all(|c| c.is_ascii_hexdigit()))
                {
                    bail!("{name} has a wheel without a SHA256 hash");
                }
            }
        }
        if !root || !virtual_root {
            bail!("Python lock is missing the requested root package");
        }
        validate_portable_urls(&toml::Value::Table(lock.graph.clone()))?;
        // No arbitrary project settings or build systems are accepted from a lockfile.
        if lock.project.len() != 1 || project.len() != 4 {
            bail!("unsupported Python lock project settings");
        }
        Ok(())
    }

    pub(super) async fn install_uv_lock(
        &self,
        ctx: &InstallContext,
        tv: &ToolVersion,
    ) -> Result<()> {
        let lock = tv
            .uv_lock
            .as_ref()
            .ok_or_else(|| eyre!("missing uv lock"))?
            .load()?;
        self.validate_uv_lock(tv, lock)?;
        let uv = self.lock_uv_program(&ctx.config).await?;
        let (python, _) = tv.uv_python.as_ref().ok_or_else(|| {
            eyre!(

View on GitHub (pinned to 533346cc37)