zvm

ID

zvm

Home page

https://github.com/tristanisham/zvm

Platforms

🐧 Linux · 🍎 macOS · 🪟 Windows

Operations

installed · search · install · remove · cleanup

purl types

pkg:zvm

CLI name

zvm

Issues and PRs

📦 manager: zvm

Source

meta_package_manager/managers/zvm.toml

zvm installs and switches between versions of the Zig compiler (https://github.com/tristanisham/zvm).

A package is a version token, and every verb agrees on it: install, rm and use all take one, and the listing prints one per line. Both shapes are real packages, a released number such as 0.13.0 and the rolling master, which is the reading rustup and bob settled: the object every verb accepts is what counts as a package.

Parsing notes, verified against zvm 0.9.1 on macOS:

  • No installed_version is captured, deliberately, as for bob and pyenv. The token is the identity rather than a version field, and master is not a version at all.

  • The inventory prints bare tokens, one per line. Its empty state is a sentence rather than a blank, “No local Zig installs. Run zvm ls --all …”, which the pattern rejects on the spaces alone.

  • The catalog is a three-column table whose header the pattern has to reject, so it matches the two token shapes explicitly rather than anything at the start of a line. Dropping master would have been the easy mistake: it sits on the last row, formatted master (remote) (0.17.0-dev…), and it is installable like any other.

  • No upgrade_all, and the name is the trap. zvm upgrade is documented as “Self-upgrade ZVM”: it replaces the tool, not any installed Zig. Nothing upgrades a compiler in place either, a newer one being an install, so no upgrade of any kind is declared.

  • No outdated: nothing reports staleness.

Note

Installs are verified twice by zvm itself, against a shasum and a minisign signature, both reported on the way through.

What mpm adds to zvm

Through mpm, zvm gains --exact and --extended search, to narrow to exact names or match descriptions.

Bigger still, mpm reaches across every manager at once: mpm installed and mpm outdated cover zvm alongside every other manager you run in one table, mpm upgrade --all updates them together, and mpm sbom exports the whole machine as one bill of materials.

Every mpm command also gains --dry-run and --plan previews, cross-scheme version comparison and purl identifiers. See manager augmentations for how each one is built.

Your zvm commands, in mpm

You already know zvm: each operation maps one-to-one onto mpm, in an interface shared by every manager.

To…

With zvm

With mpm

List what’s installed

zvm ls

mpm --zvm installed

Search for a package

zvm ls --all

mpm --zvm search ls

Install a package

zvm install <package_id>

mpm install pkg:zvm/<package_id>

Remove a package

zvm rm <package_id>

mpm remove pkg:zvm/<package_id>

Clear caches

zvm clean

mpm --zvm cleanup --cache

Prefix any command above with --dry-run to simulate the underlying manager calls without touching the system: the safe way to watch what mpm would do before trusting it.

Operations

Operation

Supported

Notes

installed

✓

outdated

orphans

search

✓

exact and extended search backfilled by mpm

install

✓

upgrade

upgrade_all

remove

✓

sync

cleanup

✓

doctor

Selecting and configuring zvm

Deselect zvm for a single run with --no-zvm, or persist the choice in your configuration:

[mpm]
zvm = false

Keep it enabled but tune how mpm drives it with a per-manager override:

[mpm.managers.zvm]
timeout = 900

mpm config-template zvm prints every overridable attribute as a ready-to-paste block.

Recipes

A few jobs you would otherwise script around zvm, one mpm command each:

  • Snapshot and clone a machine: mpm --zvm dump zvm.toml, then mpm restore zvm.toml on the next one.

  • Export a compliance SBOM: mpm --zvm sbom (CycloneDX by default, --spdx for SPDX).

Privilege escalation

mpm runs this manager as the current user and never prepends sudo by default. Flip the policy for its privileged operations with --sudo or the per-manager sudo override.

None of its operations needs root.

See privilege escalation for the full policy.

Cooldown

State of zvm’s release-age gating, from the cooldown support table:

Status: ❌ None (the catalog lists versions, never their release dates)

A cooldown only pays off where a compromised release can be withdrawn while the clock runs, and can only be emulated where the registry dates its releases. From the retraction table:

  • Registry: Zig release archive

  • Retraction: Archive removal: a compiler is a tarball on ziglang.org or a mirror, so a version is withdrawn by that archive ceasing to serve it, with the index regenerated to match

  • Publish date: ❌ the catalog prints a version and a tag marker, never a publication date

With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --cooldown best-effort opts back in.

Version probe

The version is probed by running:

$ zvm --version
zvm version v0.9.1 darwin/arm64

and extracted with:

r"zvm\s+version\s+v?(?P<version>\d+\.\d+\.\d+)"

Reference traces

Raw native outputs captured in the bundled definition: the reference mpm’s parsers were written against. If you know zvm well and a transcript below looks wrong, or a newer release changed its output format, report it.

$ zvm ls
0.13.0

$ zvm ls --all
Version     Installed   ZLS
0.16.0                  (tagged)
0.13.0      [installed] (tagged)
master (remote) (0.17.0-dev.1936+5a625d5f3)

Feed any of these through mpm and the raw output becomes one uniform table, the same shape for every manager: filter it, project columns, or export it (mpm --zvm installed --output json, or csv, toml, yaml), each package carrying a purl and a version comparable across managers.

Changelog

  • 8.0.0.dev0 (unreleased)

    • Add zvm Zig version manager, with inventory, catalog search, install, remove and build-cache cleanup.