Add Manager

Add a new package manager

$ARGUMENTS names the manager to wrap, or the GitHub issue requesting it.

Implement support for a new package manager in mpm, or complete an incomplete integration. If adding a manager requested via a GitHub issue, extract CLI output samples from the issue body to guide the implementation.

Confirm the tool is a candidate

Not everything that installs software is one. Two grounds disqualify a tool outright, whatever its popularity, and neither is a judgement about effort:

• A dead upstream. The stability policy flags an abandoned manager unmaintained, hides it from default selection, drops it from the test matrices and eventually removes it altogether. A wrapper written for an already-retired tool starts at the end of that lifecycle, so it is not written. Almost no project announces its own death, so measure the silence instead of waiting for a statement. Requiring an explicit discontinuation notice leaves a tool unassessed forever: of six checked this way, none published one and five were plainly retired. Read the newest artifact the project actually produces, and dig past the front page into the repository, its issues and its pull requests. Enthought Canopy's newest release note is dated 23 April 2018, apt-rpm last released in 2006, and openpkg.org now answers with an expired TLS certificate. Any of those settles it where a notice never comes.

  Measure before believing a record that calls something dead. Re-checking one list of "long dead" tools found five alive, including two live distribution package managers, netpkg and upkg, whose distributions had shipped releases within the year. A verdict inherited from a catalogue or an earlier pass is a lead, not a fact.

• No registry of its own. A tool that merely unifies syntax or declarations across other package managers reaches no package mpm cannot already reach through the backend it wraps directly, so wrapping it buys a translation or reconciliation layer and not one extra package. This is what rules out the declarative multi-backend managers (metapac, decman, declaro) and the syntax shims (upt) — several of them actively developed. Such a tool may still deserve a benchmark column as a peer of mpm; that is a separate question from wrapping it.

Target the live end of a lineage rather than whichever name is most familiar. Shougo's Vim managers ran neobundle → dein → dpp.vim before Neovim absorbed the job into core, and mpm wraps vim-pack alongside lazy; on the Zsh side antibody gave way to antidote, which mpm wraps next to zinit. Siblings are not a lineage: two live tools serving one ecosystem are each judged on their own, and wrapping one says nothing about the other. A lineage can also fork, and then each successor is judged separately: packer.nvim's unmaintained notice names both lazy.nvim and pckr.nvim.

That fork is the worked example of the criterion that decides an editor or shell plugin manager, since neither ships a package database mpm can query directly. Ask whether the tool can be driven to completion with nobody at the keyboard. lazy.nvim can, through a headless Neovim plus a JSON lockfile listing installed plugins without starting the editor, which is why it is wrapped. pckr.nvim cannot, and the way it lost the ability is the lesson: packer.nvim documented a headless recipe closing on a User PackerComplete autocommand, and the rewrite emits no autocommand at all, so nothing signals completion, while removal blocks on an OK to remove? [y/N] prompt and the lockfile is opt-in, Lua rather than JSON, and keyed by URL. A request for a synchronous entry point was closed with a redirect to config and dependencies (lewis6991/pckr.nvim#12). dpp.vim cannot either: its work runs in a Deno process the editor starts, with no headless entry point documented at all. Design that entry point in from the start when proposing a manager upstream; retrofitting one meets resistance.

Ask whether the headless path is a stated contract or an accident of the current implementation, and re-check it after any upstream rewrite. packer.nvim's was as deliberate as they come, a recipe in its own readme, and it still did not survive the rewrite that replaced it, so a successor inherits nothing here and has to be assessed from zero. micro is the shape to look for: its help states the plugin manager is invoked "with the > plugin ... command, or in the shell with micro -plugin ...", so the shell path is something upstream committed to rather than a flag that happens to be handled before the screen initializes. Where a wrap has to rest on incidental behavior instead, say so in the class docstring, so that the next failure is read as an upstream change rather than a parser bug.

A candidate is not required to support every operation. Inventorying and updating are enough on their own, and a missing install disqualifies nothing. That pair already beats what the competing wrappers do for the same tools, which is a coarse upgrade of a whole category with no listing at all, so wrapping at that level turns an opaque bulk update into something a user can inspect. topgrade is wrapped on upgrade_all alone, and lazy on inventory plus update: lazy.nvim materializes only the plugin set the user's own Lua configuration names, so an install would mean mpm editing configuration it does not own. Declare the operations the tool genuinely supports, let mpm auto-skip the rest, and record in the class docstring why each absent one is absent. Never fake an operation with a mutating command.

There is a floor under that, and topgrade is where everything below it goes. topgrade sits in the pool precisely as the catch-all for tools too thin to wrap on their own: it auto-detects and upgrades whatever it finds on the host, so every tool it drives is already reachable through mpm upgrade --topgrade without mpm learning any of them. That makes it the sinkhole, and it changes what a marginal candidate has to prove.

Apply the test in this order:

1. Does the candidate offer an inventory? If it can list what it has installed, wrap it. That is the one thing topgrade categorically cannot do for any tool, having no listing at all, so the inventory is the whole gain and a missing install/remove/outdated does not diminish it. This is why lazy, vim-pack, zim and zplug are wrapped on inventory plus update.
2. If not, does it offer any per-package operation? A tool with no listing but real install or remove verbs still reaches packages one at a time, which topgrade cannot. steamcmd is wrapped on install alone on those grounds, and sheldon on remove plus update.
3. If neither, and topgrade already drives it, decline. A wrapper whose entire honest surface is upgrade_all buys one more way to run an upgrade mpm already reaches, at the cost of a full manager's checklist and its ongoing maintenance. zr is the worked example: plugins are the arguments you hand it, so it owns no inventory, and zr --update is already inside topgrade's catalog.

Check docs/benchmark.toml before leaning on step 3: it is only an argument for tools topgrade actually covers. A thin tool topgrade does not drive reaches nobody, and is judged on its own merits.

Three further requirements are enforced in code. They are not preferences: a tool that cannot clear them cannot be wrapped in the current architecture, however much work is thrown at it.

The first two have escape hatches worth trying before declaring a tool impossible. A shell-function manager can key on the interpreter that runs it instead of on its own sources: zinit and antidote are both wrapped that way, with Zsh as their CLI and their version probe doubling as the presence check. Check the file mode before assuming otherwise, since a shebang is not an executable bit: antidote ships its CLI mode 644 and Homebrew installs it as package data under share/, never linking it into bin. A manager whose own binaries expose no version can name a companion binary through CLIExecutor.version_cli.

Keying on a shared interpreter raises a second problem, which that same probe solves. Two managers may legitimately want the same binary: vim-pack and lazy both run nvim. What separates them is that each probe reports a version only once its own tool is found, lazy by testing for the lazy.nvim checkout before putting it on the runtime path, so a host with a bare editor leaves it unavailable rather than shadowing every machine that has one. Guard the probe so an absent tool exits cleanly and prints nothing, instead of raising.

dein.vim is the worked example of both hatches failing, and the shape to compare a candidate against. It is Vimscript with no binary anywhere, and nothing to test for that would make an nvim or vim probe conclusive the way lazy's is. It reports no version either: g:dein#_cache_version is an internal state-format counter, and its releases are Git tags on a checkout the user places freely.

When a tool is rejected, record the decision rather than leaving it implicit: add a section to docs/unsupported.md and an entry to the unsupported table of docs/benchmark.toml. Title the section with the tool as a linked code span followed by its glyphs ([`paq`](https://github.com/savq/paq-nvim) ❌ 🛟), and keep the page sorted by title. Sort the key against the whole list rather than eyeballing the line above it: the unsupported table of docs/benchmark.toml sorts by manager id while the sections of docs/unsupported.md sort by title, so topgrade precedes tpack on the page while toolbx precedes tpack in the table, and a family section titled after its family sorts under that title rather than under any member. Both orderings are asserted by tests/test_docs.py. Where an existing section already carries that verdict word for word, add the tool to its member list instead of copying the paragraph. The benchmark then renders a ❌ linking straight to that section instead of a blank cell. That changes the rendered table, so run click-extra refresh-directives readme.md docs afterwards or test_mirror_blocks_in_sync fails: a decline is never a docs-only edit.

Every tool assessed gets one of the two outcomes, always. Wrapped, or written down as unsupported with a rationale. Nothing is left in between, including a tool waved off in passing during a discussion: that is still a decision, and an unrecorded one is indistinguishable from an unexamined one. The target is total coverage of everything that installs software, so a blank benchmark cell is a gap to close rather than a neutral state, and "not worth wrapping" is a rationale to write out, not a reason to skip the row.

Ground the reason upstream whenever the blocking behavior has been raised there. Search the tool's tracker for the missing capability and link what you find: a feature request closed not-planned, a maintainer stating the position, or an open request left unaddressed for years. Quote the deciding sentence and anchor the link on the exact #issuecomment-<id> when a comment is what settles it, exactly as the benchmark's ❌ cells do. zgenom is the worked example: its decline rests on reporting no version, and the request to tag releases was closed on the maintainer's own "I consider everything merged into main as a stable release". That turns a verdict a reader has to trust into one they can audit, and it dates the decision, so a tool whose upstream later changes course can be reassessed against the same link. When no such discussion exists, say so rather than implying one: an absence that is deliberate design (zr treats plugins as arguments and so owns no inventory) is itself the reason.

Drive the tool before writing it

Install the candidate, run every verb, capture the output. This is the step that pays: bob's catalogue omission, spack's environment scoping and getnf's colour handling were each invisible from the documentation, and each would have shipped a broken definition. Documentation is a starting point, never the authority.

Check available first, because a broken version probe hides every other defect. A manager whose probe returns nothing is never available, so none of its operations ever run and none of its bugs can surface: the code reads as finished and is untested end to end. ports sat that way, probing a .MAKE.VERSION variable make(1) does not document, and behind that one dead line waited three more bugs, in installed, outdated and the origin lookup, none reachable until the probe was fixed. Confirm the manager reports a version and available: True on a real host before trusting anything downstream of it, and treat a manager never driven on its own platform as unverified however complete it looks.

Read the argument parser, not the readme. Where a tool ships its parser in one readable file, that file is what settles the verdict. pkgit's readme lists neither --version nor --list while src/parse_args.c handles both, so a readme-only reading would have declined a genuine candidate twice over. choosenim and gup are the same shape: gup update <name> runs although its own usage line documents gup update [flags] alone.

Check what the competitor actually drives before trusting a home page. A benchmark row's URL can name a different project entirely: the voom row linked a Vim outliner that installs nothing, while topgrade's run_voom requires a voom binary and runs voom update, which is airblade/voom. Reading the competitor's own step source settles it in one call.

Run the candidate under a repointed HOME so its state never lands on the real machine, and know what that does and does not buy:

• Not every tool honours it. bob resolved its data directory to the real ~/.local/share/bob regardless, and roswell reads and writes ~/.roswell whatever $HOME says: 37 MB and 248 MB respectively, on the actual machine. Check where a tool reports installing before assuming the sandbox held, and check PATH too, since 0install wrote its launcher into the first writable bin it found.
• A repointed HOME silently disables the cooldown safeguard. A host config setting cooldown fail-closes managers that cannot enforce it natively; under a scratch HOME no config is found, so an install succeeds where a real user would be refused. Verify both ways, or at least know which one produced the green.
• A long scratch path breaks tools with a socket under $HOME. 0install failed on can't connect to the keyboxd: File name too long, which is the path overflowing the Unix socket limit rather than anything about the tool. Drive from a short path such as /tmp/mpm-drive.
• A GPG-verifying tool needs the command sandbox off. Past the path limit, the same tool failed on IPC connect call failed, because the sandbox blocks the socket keyboxd listens on, leaving every feed signature unverifiable. The symptom names the daemon, never the sandbox.
• A downloaded release binary cannot be made executable where chmod is denied, so that route dead-ends at a 644 file. Prefer a channel that sets the bit itself: pkgx <tool> runs anything in its pantry, and go install <module>@latest writes an executable binary, which is how zvm was wrapped after being abandoned once on exactly this. Check whether a blocked candidate is written in Go before recording it as undrivable.

Fixtures come from that driving and nowhere else. Never invent a sample and never trim one: a shell-session block is a complete capture that has to parse through the manager's own parser. Where a needed state is missing, create it for real. getnf's unknown version row came from deleting a release marker, elan's orphan report from clearing default_toolchain out of elan's own settings, and gup's outdated fixture from downgrading a binary to an older tag. A capture that parses is not thereby genuine: the corpus test proves a block matches the parser, never that the tool emits it. ports documented a = up-to-date with port row under a flag whose whole job is to exclude that status, so the line parsed cleanly for years and the command could not have produced it. Re-run the exact documented argv and diff its output against the block whenever a fixture predates your own driving.

A tab-indented fixture cannot survive in a docstring. ruff format rewrites a docstring's indentation, so a leading tab reaches the corpus as spaces and a parser keyed on \t at line start fails only after the formatter runs. go's listing hit this: its parser now ignores leading whitespace and keys on the field separator instead. Run the formatter before trusting a green corpus test, and prefer a parser that does not depend on how a line is indented. A bundled TOML definition is immune, its samples living in the TOML file rather than in Python.

Choose an implementation strategy: class-based or config-based

Before writing anything, decide how the manager will be implemented. mpm supports two paths:

• Class-based: a Python module in meta_package_manager/managers/. Full power: multi-line or stateful output parsing, version pinning, per-operation search flags, conditional sudo, delegation, arbitrary logic. It is the most capable path, and what the rest of this document describes.
• Config-based: a declarative [mpm.overrides.<id>] block that mpm turns into a live manager at startup, with no Python (documented in {doc}/overrides, "Define a new manager"). Quick to write, but constrained: each operation is a fixed argument list, and listings must parse either line-by-line with a single regex or as one flat top-level JSON array. The DSL covers sibling binaries (a per-operation cli key), unconditionally privileged operations (a per-operation sudo = true key plus a manager-level default_sudo), and version probes on a companion binary (version_cli, for suites versioned with the OS). A definition can live two places: in a user's own trusted configuration file (a private, per-machine manager), or bundled with mpm as read-only package data (a manager shipped to every user, like a built-in). The bundled path is how mpm distributes a simple manager as data instead of code.

Reach for config-based only when every one of these holds. If any fails, the manager needs a class:

Config-based skips the class machinery: no Python module, no pool.py registration, no version pinning or delegation. A private definition needs nothing beyond your own config file; shipping one bundled adds only a short metadata checklist (see below). Reach for a class when the manager needs power the DSL cannot express, and upstream it if it would help others: {doc}/overrides and {doc}/security explain why a reviewed, shipped manager beats executable configuration.

Whatever the path, identify the tool's escalation model before mapping operations — each demands a different treatment:

• Plain root-requiring (most system managers): mark mutating operations privileged (sudo = true in a definition; run_cli(..., sudo=True) plus default_sudo = True in a class).
• Self-escalating (fink re-execs itself under /usr/bin/sudo and no-ops when already root): never mark operations privileged, or sudo stacks on sudo.
• Broker-based (pkcon hands transactions to a polkit-authorized daemon): no escalation at all; note that unattended runs depend on the broker's policy.
• Root-refusing (chromebrew hard-aborts as root): no escalation, and never wrap in sudo manually.

Also check whether the platforms tokens exist in extra-platforms (VALID_PLATFORM_TOKENS accepts any platform or group ID). A missing distro detection is an upstream extra-platforms addition (same author): land it there, track git main via [tool.uv.sources] until the release, then relax to the PyPI floor. The new-manager issue template's platform checklist derives from MAIN_PLATFORMS and is enforced by test_new_package_manager_issue_template, so regenerate it when platforms land.

Config-based managers

The declarative schema (required keys, every operation, the regex and JSON parsers, placeholders, worked examples) is the "Define a new manager" section of {doc}/overrides, which is the source of truth. This section adds only the authoring workflow and the pitfalls that decide success.

1. Capture real output first. For each operation you plan to declare, run the actual CLI and paste its output. Confirm a single per-line regex or one flat JSON array can extract package_id (plus installed_version for installed, latest_version for outdated). Never assume a format.

   A tool that does not belong on this host is usually still runnable, and reading its source is the last resort rather than the first. Try these in order before falling back to it:

   • Run it in a throwaway sandbox. Most managers root everything they touch at $XDG_* or one environment variable, so repointing those at a scratch directory gets a real install, a real listing and a real removal without touching the user's machine. Fetch the release binary rather than installing the tool for real. Miss one variable and the tool reaches for the real home, which the sandbox refuses: read that refusal as the hint it is (yazi needed XDG_CACHE_HOME on top of the other three).
   • Feed the real tool synthetic state. When the inventory is read off disk, fabricate the on-disk shape and let the tool parse it: a mason receipt, a bin config naming deliberately stale binaries, a metadata.json per GNOME extension. The parser under test is the tool's own, so the output is genuine even though the packages are not.
   • Drive the tool's own code with the host-specific call stubbed. For a manager written in an interpreted language, import its command handler and replace only what needs the absent platform, leaving its formatter and command flow real. gext's listing was captured on macOS this way, stubbing the one call that shells out to gsettings; its search and dry-run needed no stub at all, hitting the live registry.

   Only when all three fail, derive the format from upstream: read the exact printf/echo/print statements that emit each line in the tool's source, cite them, and mark reconstructed samples as source-derived in comments. Never invent output.

   Whatever the route, ask what the default listing omits before trusting it. gext list shows only enabled extensions until --all, and micro's shows only loaded plugins. A listing that silently drops half the inventory is worse than one that errors.

2. Write the block. Add [mpm.overrides.<id>] with an <id> that no built-in uses. Set platforms, the operations table, and the identity fields (cli_names, requirement, version_regexes, ...). Silence color and interactivity via pre_args, post_args or extra_env (like NO_COLOR = "1") so the parser sees clean text. mpm config-template prints the built-ins' overridable fields as a formatting reference.

3. Declare only expressible operations. A manager with no non-mutating "list upgradable" command (common: soar, appman, gh extension) omits outdated; mpm auto-skips it and upgrade --all still works. Never fake an operation with a mutating command.

4. Validate against the real CLI. mpm checks the definition at load and reports the first problem with a precise path:

   $ mpm --config ./my-managers.toml managers
   $ mpm --config ./my-managers.toml --<id> installed
   

5. Add tests. For a private definition, mirror tests/test_manager_definition.py: parse_manager_definition for validation cases, build_manager_class(...) with a monkeypatched run_cli for parsing, and the fake_tool fixture for an end-to-end run through a real subprocess. For a bundled definition, ship the [samples] fixtures in the TOML file itself instead (see the checklist below): the suite globs the shipped files and derives its checks from them.

Design around the DSL's fixed limits (all detailed in {doc}/overrides): no version pinning (install and upgrade always take the latest, {version} is never substituted); listings are line-by-line regex or a single flat JSON array, with no multi-line records, pagination, or value transforms; search cannot declare native exact or extended filtering, so mpm refilters the results itself. If any of these is load-bearing for the manager, stop and write a class instead.

Where a config-based definition lives

A definition has two homes:

• Private (a user's config). Drop the [mpm.overrides.<id>] block into your own configuration file. mpm picks it up on the next run: nothing else to touch, and it never leaves your machine.
• Bundled (shipped with mpm). Put the block in its own meta_package_manager/managers/<id>.toml file. mpm loads every shipped *.toml at startup and registers it like a built-in, so every user gets its --<id> flag. Bundled files are read-only package data, so they load without the config-file trust gate that guards a user's own definitions (see {doc}/security). meta_package_manager/managers/gh_ext.toml is the worked example.

Shipping a bundled definition is far lighter than the class-based checklist below, with no module:

…(truncated)