Meta Package Manager: one CLI to snapshot and restore every package manager

What Meta Package Manager is actually solving

The problem is that a modern workstation is not managed by one package manager. A single macOS laptop might have Homebrew formulae and casks, the Mac App Store, pipx, pip in a virtualenv, npm globals, Ruby gems, Cargo binaries, and maybe a Flatpak or two. Linux machines add apt, dnf, pacman, snap, Nix, and language specific managers on top. Asking what is installed means asking every one of them, and reproducing that set on a new machine means running through each of them again by hand.

Meta Package Manager, whose CLI is mpm, addresses exactly that. It snapshots every package on your machine to one file and restores it on a new one. The project compares it to yt-dlp but for package managers instead of videos, and it positions the tool as a solution to the universal install script problem from XKCD #1654.

The author is explicit about the primary use case: upgrading all outdated packages from every manager at once, described as the main reason the tool was built. The stated motivation links to a claim that 70 percent of vulnerabilities lie in outdated libraries, and the design response is a release-age cooldown that refuses any version published more recently than a threshold.

The audience is a developer or IT generalist who has more than one machine and wants a single inventory, a single upgrade command, and a portable record of what they had installed.

mpm dump and mpm restore: the manifest is the portable artefact

The core workflow is two commands. The first takes an inventory of every manager on the system and writes it into a single file, in TOML manifest form or as a Brewfile, and the command is `mpm dump packages.toml`. The second reads that file back and reinstalls the same set of packages on a new machine with `mpm restore packages.toml`.

Neither command is a script you have to write. The manifest is the artefact that travels.

What makes this more than a wrapper is that it spans managers, not one. The tool can also list the package managers available on the system, list installed packages, list duplicate installed packages, search for packages, install a package, remove a package, list outdated packages, list orphaned packages, sync local package infos, and diagnose the health of package managers with mpm doctor.

Two details are worth knowing. The outdated listing picks out the differing part of each version in colour, so a patch bump reads apart from a major one at a glance. And mpm runs the managers concurrently unless they share the same backend, which is the sort of detail that decides whether a full sweep takes a minute or ten.

The manifest can be pointed at a subset of managers through include and exclude selectors, so a machine that mixes apt, pip and npm can be snapshotted with only those three, and package specifiers can be plain, versioned, or expressed as purl package URLs.

Upgrading every manager at once, and the cooldown that guards it

The upgrade command is where the author says the tool earns its keep, and it is also where the risk lives.

A manager that fails during an upgrade is marked with a cross symbol and named in a closing summary, while the others carry on. That is the right behaviour for a sweep across a dozen managers, since one broken backend should not abort the rest.

After the sweep you get a report of what each command changed, available at the end of install, remove, upgrade, restore and cleanup --orphans. The report names every package upgraded, downgraded, installed, removed, held back by the cooldown, or still outdated, with its versions. A tool that touches twelve package managers on your machine should be able to tell you exactly what it did, and this one can.

The supply-chain protection is the release-age cooldown. It refuses any version published more recently than a threshold you set, and a manager that cannot enforce that window is skipped rather than run unguarded. That is a sensible design: a manager without the ability to refuse a fresh release is not upgraded at all, instead of being upgraded without the protection you asked for.

There is also a command to export an SBOM, which writes the installed packages to SPDX and CycloneDX files. That is useful when a compliance question arrives about what is running on a machine, since the inventory you need is the same inventory the dump command already produces.

mpm doctor and the managers that get skipped

The tool has a command to diagnose the health of package managers, and it also has a command to inventory and list every package manager available on the system. Both exist because mpm is a wrapper over other tools, and wrappers fail in a specific way: the underlying tool is missing, is the wrong version, is authenticated out, or is configured differently than the wrapper expects.

The supported roster is long. The documentation lists managers by name including am, antidote, antigen, apk, apm, app-manager, apt, apt-cyg, apt-mint, aptitude, and continues through the alphabet to cover ecosystems as different as cargo, composer, conda, cpan, ctan, dnf, dnf5, dotnet, elan, emacs, emerge, eopkg, exherbo, fink, fisher, flatpak, fwupd, gcloud, gem, gext, ghcup, guix, gup, haxelib, homebrew, hyprpm, jpm, julia, krew, lazy, luarocks, mageia, mamba, mas, mason, microdnf, micromamba, and more. The pyproject.toml keyword list is a second copy of the same roster, with the platform and distribution names mixed in.

The roster is generated rather than hand maintained. The project embeds a snippet in its own documentation pipeline that imports manager_roster from the package and prints it, so the list of managers in the docs comes from the code.

This is also where the tool admits its own nature. The documentation notes that because mpm tries to wrap all other package managers, it became another pathological case of the XKCD #927 standards comic. The joke is fair. A tool that spans this many ecosystems inherits every inconsistency they have, which is exactly why mpm doctor and the per manager health checks exist.

Platforms, menu bar plugins and how to install it

mpm runs on macOS, Linux, Windows, FreeBSD, NetBSD, OpenBSD, illumos and Solaris, with standalone executables for the first three of those. The package is published on PyPI as meta-package-manager, and the project documentation has an install page for it.

Two graphical front ends exist. There is a SwiftBar and Xbar plugin for the macOS menu bar, and a GNOME Shell extension for Linux. Both list the outdated packages of every manager on the system and let you upgrade them from the menu, which turns a periodic chore into a glance at a menu bar item.

Shell auto-completion is provided for Bash, Zsh and Fish, and output can be exported as JSON or as user friendly tables, so the tool fits into scripts as well as into a terminal session.

The project builds with uv, and the packaging metadata in pyproject.toml names the build backend:

[build-system]
build-backend = "uv_build"
requires = [ "uv-build>=0.8" ]

The package version in that file is 8.1.3.dev0, a development version ahead of the last tagged release, v8.1.2 on 2026-10-12, with v8.1.1 on 2026-10-09 and v8.1.0 on 2026-10-04. Three releases in eight days is a fast cadence for a tool that touches system state, so reading the changelog before upgrading mpm itself is sensible.

Where Meta Package Manager is the wrong tool

The first wrong case is a machine whose package state is managed declaratively already. If your workstation is defined by a dotfiles repository with a script that runs brew bundle and a requirements file, then a manifest tool is a second source of truth, and two sources of truth drift. The difference in approach is real: a manifest records what happened to be installed, while a dotfiles setup describes what should be installed, and only the second one converges.

The second wrong case is a production or shared server. mpm upgrade is an interactive sweep over many backends, and the reports it produces are aimed at a person reading a terminal. It has no notion of idempotent convergence, of a dry run followed by a policy check, or of a change request. On a server you want a declarative tool, not a coordinated wrapper.

The third is a container image build. The same argument applies: a Dockerfile with explicit installs is the declaration, and a dump of whatever happened to be in the image is not.

The fourth is a permission model mismatch. Several of the supported managers write to system directories and need root, and some need interactive authentication. mpm is a coordinating layer, so it inherits the strictest requirement of the managers it wraps. On a machine where you cannot sudo, some managers simply will not work, and the tool will report them as failures rather than as unavailable.

There is also a data risk. A manifest is a snapshot of what was installed, including versions. Restoring it later installs the versions captured at dump time, not the versions that would be current then, so a restore is a reproduction rather than an upgrade. That is the correct behaviour for reproducing a machine and the wrong behaviour for keeping one patched, and the two goals need different tools.

Licence, packaging and the cost of upgrading mpm itself

Meta Package Manager is released under the GPL-2.0 licence, with the text in the license file at the repository root. GPL-2.0 is a strong copyleft licence, and the practical consequence for a tool like this is that if you modify it and distribute the modified version, you have to publish that version's source. Merely running it on your own machine, or using it inside a company, does not create that obligation, but shipping a modified mpm inside a closed product does. Read the license file yourself and take your own advice on it.

The rest of the packaging is conventional. The project uses uv for its build and ships a uv.lock file, and the source lives in a meta_package_manager/ directory alongside tests/ and docs/. There are separate directories for the packaging metadata and for the two graphical integrations, the gnome-shell/ directory for the GNOME Shell extension, and a packaging/ directory for distribution recipes.

The repository also carries a citation.cff, a DOI badge pointing at a Zenodo record, and a changelog.md, which together mean you can cite the tool in a paper and read a proper release history. There is a .gitlab-ci.yml in addition to the .github/ directory, and a claude.md file, which tells you the project has been set up for AI assisted development and has committed to that workflow rather than treating it as incidental.

The last push was on 2026-10-20, so the tree is current, and the repository is not archived.

Editorial conclusion

Meta Package Manager fits a developer or sysadmin who owns several machines and wants one reproducible file describing what is installed, plus a single command to upgrade every manager behind it, and its mpm dump and mpm restore pair is the part worth adopting. It does not fit a system where each manager has its own source of truth and a deployment pipeline, because mpm coordinates managers rather than replacing them, and the GPL-2.0 terms mean a modified version distributed inside a closed product has to be published. Before you rely on it, run mpm doctor on your own machine to see which managers it detects and which it skips, dump a manifest and diff it against your expectations, and check the release-age cooldown behaviour before letting it upgrade anything unattended.

Frequently asked questions

Official sources

1. kdeldycke/meta-package-manager on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases