jdx/mise · error

swift does not publish musl builds

Error message

swift does not publish musl builds

What it means

mise lock resolves a PlatformInfo (URL + checksum) for each tool so lockfiles stay reproducible. For swift on Linux, every swift.org build links against glibc — there is no musl variant — so when the target's libc is musl the resolver fails on purpose instead of recording a URL that does not exist; mise lock then reports swift as skipped rather than writing a bogus entry.

Source

Thrown at src/plugins/core/swift.rs:246

    /// A lock entry without a `swift_platform` option was written before the
    /// distro was recorded, so which artifact its checksum describes is
    /// unknowable. Such entries still pin the version; their checksum and URL
    /// are ignored and rewritten for this host's distro on install.
    fn lockfile_options_are_host_specific(&self) -> bool {
        true
    }

    async fn resolve_lock_info(
        &self,
        tv: &ToolVersion,
        target: &PlatformTarget,
    ) -> Result<PlatformInfo> {
        // Every published Linux build links against glibc, so there is nothing
        // to lock for a musl target. Fail instead of recording a URL that
        // doesn't exist, so `mise lock` reports it as skipped.
        if target.libc() == Some("musl") {
            bail!("swift does not publish musl builds");
        }
        let url = url(tv, target);
        // Not every distro/arch pair is published — `ubi9` has no aarch64 build,
        // for instance — and which pairs exist changes per release, so ask rather
        // than encode a matrix that would go stale. This keeps a lockfile from
        // recording an artifact that isn't there.
        if let Err(err) = HTTP.head(&url).await {
            bail!("swift does not publish {url}: {err}");
        }
        // swift.org publishes no checksum sidecar (only a detached GPG
        // signature), so a checksum can't be resolved without downloading the
        // whole ~1GB toolchain. Record the URL the entry describes; the checksum
        // is filled in when the tool is installed.
        Ok(PlatformInfo {
            url: Some(url),
            ..Default::default()
        })
    }

View on GitHub (pinned to 6f52dcdf99)

Solutions

  1. Run lock generation on a glibc-based image/host (debian, ubuntu, ubi, amazonlinux) — or exclude that musl target from swift locking
  2. If you genuinely need swift on Alpine, no official build exists: switch the container to a glibc base or use a swift docker image instead of mise-managed swift
  3. Accept the skip: `mise lock` marks swift as skipped on musl — verify the lockfile simply lacks a swift entry and don't force it
  4. For local dev on Alpine, run swift in a glibc container (devcontainer/Docker) rather than via mise

Example fix

# before (Dockerfile)
FROM alpine:latest
RUN mise lock   # -> swift does not publish musl builds

# after
FROM debian:bookworm-slim
RUN mise lock
Defensive patterns

Strategy: validation

Validate before calling

# refuse to lock swift from a musl host, before mise lock:
[ "$(ldd --version 2>&1 | head -1 | grep -o musl || true)" ] && { echo "swift unavailable on musl; using glibc container"; exit 1; }
mise lock

Prevention

When it happens

Trigger: Running `mise lock` (or any flow that resolves lock info) for swift while the platform target's libc is musl: Alpine hosts, distroless/scratch musl containers, Nixpkgs musl runners. resolve_lock_info checks target.libc() == Some("musl") before anything else.

Common situations: CI on alpine images with a mise.toml that includes swift; developers on Alpine workstations; lockfile generation for multi-platform matrices where one target is musl-based.

Related errors


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