add-manager

name	add-manager
description	Implement support for a new package manager in mpm, or complete a partial integration. Covers vetting the candidate, choosing between a Python class and a declarative definition, mapping operations, the cross-file checklist, and validation. Use when wrapping a new tool, finishing a half-wired manager, or recording why a tool was declined.
compatibility	Designed for Claude Code. Recommended model: Opus.
allowed-tools	Bash Read Write Edit Grep Glob WebFetch WebSearch Agent
argument-hint	[manager name or GitHub issue URL]

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.
• 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.

Requirement	Enforced by	What it rules out
An executable CLI	CLIExecutor.executable	A tool shipped only as a file meant to be sourced, with no binary anywhere and no interpreter to key the manager on.
A reportable version	PackageManager.fresh	A tool that reports no version through any binary: without one the manager is never considered available.
System scope	ManagerScope.SYSTEM	A tool whose packages live inside one project tree rather than on the machine.

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; 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.

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.managers.<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:

Requirement	Rules out config-based when
A version command prints a regex-extractable version string, on the manager's own CLI or a version_cli companion binary.	No binary reports a usable version at all (like macOS msupdate).
installed, outdated and search each emit one package per line, or one flat top-level JSON array.	Records span multiple lines (pacman -Ss, cabal list, Solaris pkginfo -x) or the JSON is an object keyed by package or environment name (mise, pixi, pnpm).
One command per operation fully populates each package record.	A record needs enriching through a second, per-package call (pacstall --cache-info to fetch a version the listing omits): one operation is one command, so the DSL cannot chain the follow-up. A name-only listing is fine on its own (apt-cyg list, swupd bundle-list): installed_version is optional, so mpm yields those packages without a version.
Every mutating operation is one argument list with {package_id} or {query} substituted in.	An operation needs conditional sudo (static sudo = true is fine), delegation, or output post-processing. Query operations never escalate, so a listing that needs root (deb-get's outdated piggybacks on sudo deb-get update) also rules the DSL out.
Every declared operation reports through stdout on a zero exit.	An operation signals its result through a non-zero exit or writes its payload to stderr. A definition parses stdout on a zero exit and can express neither, so one such operation pulls the whole manager into a class: bin's update --dry-run exits 3 with the report on stderr, and gext's exits 17 with it on stdout. Check the exit code of every "what would change" command before assuming it is declarable, since both of these look like ordinary queries until run.

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 with an that no built-in uses. Set , the table, and the identity fields (, , , ...). Silence color and interactivity via , or (like ) so the parser sees clean text. prints the built-ins' overridable fields as a formatting reference.

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.managers.<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:

File	Change
meta_package_manager/managers/<id>.toml	The definition (one [mpm.managers.<id>] section) plus a top-level [samples] table: a [samples.version] fixture locking the version probe, and one [[samples.<operation>]] block per declared query operation, locking each parser to a source-derived output sample. Auto-discovered: the loader and the sample-derived tests glob the file up.
meta_package_manager/labels.py	Optional: a MANAGER_LABEL_GROUPS entry if the manager joins an ecosystem group, plus an unambiguous ecosystem keyword in MANAGER_CONTENT_KEYWORDS (a distro/language/brand name mpm never prints, never the ID or a CLI name). The label and its file rule derive from the pool; the content rule comes only from the keyword you add, and a manager with none gets no content rule.
docs/docs_update.py	Optional: a well-known ecosystem alias in KEYWORDS_EXTRAS when it differs from the manager ID (like gh-ext and github cli). The ID lands in the PyPI keywords automatically.
tests/conftest.py	Add a PACKAGE_IDS entry: the destructive install/remove round-trip covers bundled managers too, and the import-time assertion requires every shipped manager to carry one.
tests/test_pool.py	Increment the len(pool) assertion in test_manager_count; len(manager_classes) stays.
changelog.md	A - [<id>] Add ... entry.
docs/benchmark.toml	If the manager already had a competitor row, delete its homepages entry: the homepage now comes from the definition (test_benchmark_homepages_cover_non_pool_managers enforces).
docs/stars_update.py	Add the manager's upstream repository to , or its reason for having none to . requires every wrapped manager to sit in exactly one of the two, since the pair feeds the popularity and activity columns of the manager index.

Then regenerate the pool-derived blocks, both run by repomatic's update-docs job (a manual run is just a pre-check): docs/docs_update.py writes the PyPI keywords and labeller rules in pyproject.toml, the readme's operation-matrix platform footnotes and the manager's docs/managers/<id>.md page stub; click-extra refresh-directives readme.md refreshes the readme's Sankey diagram and operation matrix, which are <!-- mirror-src --> blocks. The benchmark, augmentations and per-manager pages need no content regeneration: their tables and sections render live at Sphinx build time. A bundled config manager needs no pool.py import or docs/meta_package_manager.managers.md automodule: those are class-only.

Completing an incomplete integration

External contributors often submit a working manager module (managers/<name>.py, pool.py, conftest.py) but skip the documentation and metadata files. See kdeldycke/meta-package-manager#1758 for a typical example: the PR added code and tests but was missing 10+ files.

When asked to "integrate further", "fill gaps", or "finish" a manager that already has code:

1. Read the existing manager module to understand supported operations and platforms.
2. Walk the file checklist below and check every file for the manager's presence. The most commonly missed files are: docs/meta_package_manager.managers.md, labels.py (group and synonyms), test_pool.py (manager count), and changelog.md. Also regenerate the pool-derived blocks: docs/docs_update.py (keywords, labeller rules, readme footnotes, manager page stubs) and click-extra refresh-directives readme.md (the readme's Sankey and operation-matrix mirror-src blocks).
3. Verify the requirement version specifier by fetching the upstream release history. Check when the features the code depends on (like --json output) were actually introduced. Contributors often default to >=1.0.0 without checking.
4. If the manager wraps or complements another (like sfsu wraps Scoop), merge them under a single 📦 manager: label by grouping them in labels.py. Use the -based suffix convention for the group name (like scoop-based) to avoid colliding with the manager ID itself; the label and its rules regenerate from the group.
5. Fetch the upstream repository (README, releases, changelog) to verify CLI output formats match the parsing code.
6. Check class attribute ordering against the base class. The test_content_order test enforces that class-level attributes and methods follow the canonical order defined in PackageManager. Common mistakes: version_regexes before post_args, or name after homepage_url.
7. If the manager delegates operations to another manager's CLI, use the Delegate descriptor from capabilities.py instead of repeating override_cli_path boilerplate. See the Delegating operations section below.

Choose a template

Pick an existing manager with a similar CLI as your starting point. Read the template file in full before starting.

Pattern	Example	When to use
Simple regex parsing	snap.py, flatpak.py	CLI outputs fixed-width or whitespace-delimited text
JSON output	npm.py, homebrew.py	CLI supports --json or structured output
Multiple compiled regexes	gem.py, dnf.py	Complex text output requiring several capture patterns
Shell function wrapper	sdkman.py	Manager is a shell function, not a standalone binary
Sibling binaries	nix.py	Different operations use different CLI binaries in the same directory
Subclass of existing manager	yay.py, paru.py, pacaur.py	Manager is a drop-in replacement or wrapper for another manager already implemented
Delegate to another manager	sfsu.py	Manager has its own CLI for read operations but delegates mutating operations (install, upgrade, remove) to another manager's binary

Subclassing is the lightest option: yay.py is only 39 lines because it inherits almost everything from pacman.py. If the new manager shares the same CLI interface as an existing one, subclass it and override only what differs.

Delegation via Delegate is for managers that share the same package ecosystem but have different CLI interfaces. Unlike subclassing, the read operations (list, search, outdated) have completely different implementations, but mutating operations reuse the other manager's methods verbatim.

Typical manager modules range from 140 to 260 lines. Larger implementations (350-570 lines) tend to involve managers with unusual output formats or many edge cases like fwupd.py, winget.py, or pkg.py.

Implementation

Create meta_package_manager/managers/<name>.py. Follow the import pattern, class structure, and TYPE_CHECKING block from your template exactly.

Class-level attributes and methods must follow the canonical order defined in PackageManager (enforced by test_content_order). The order is: homepage_url, logo, platforms, requirement, cli_names, cli_search_path, extra_env, pre_cmds, pre_args, post_args, version_cli_options, version_regexes, then operations (installed, outdated, search, install, upgrade_all_cli, upgrade_one_cli, remove, sync, cleanup).

Class attributes

Required:

• homepage_url: official project URL.
• platforms: use constants from extra_platforms (ALL_PLATFORMS, LINUX_LIKE, MACOS, WINDOWS, UNIX_WITHOUT_MACOS, etc.). Combine with tuples: platforms = LINUX_LIKE, MACOS.

Common optional:

• logo: slug of the brand mark shown atop the manager's documentation page, naming an SVG vendored under docs/assets/managers/. Run uv run -- python docs/logos_update.py --scan-gaps to see whether Simple Icons carries one; if it does, declare the slug and re-run the tool without the flag to vendor the file and refresh logos.yaml. Leave it unset when there is none, which is the right outcome for roughly a quarter of the pool: the page keeps its generic package glyph, and no placeholder is invented. Managers wrapping the same upstream share one slug (brew and cask are both homebrew), declared once on their virtual base when they have one. A tool with no mark of its own takes its ecosystem's (apt under Debian's, cargo under Rust's). Never hand-vendor a mark whose brand had its icons pulled from Simple Icons after a legal request: see the comments in winget.py and sun_tools.py.

• requirement: minimum version specifier (e.g., ">=2.0.0"). Set this to the earliest version that supports all features the implementation depends on. If the code parses --json output, check the upstream release history to find when that flag was introduced. Do not default to >=1.0.0 without verification.

  A floor on the tool is not a floor on the data it wrote. Anything a manager records on disk carries the shape of whichever release created it, so a current tool keeps serving records written years ago and a parser reading only the newest shape drops those packages silently rather than failing. mason is the worked example: its receipts carry their own schema_version, the source sits under source from 2.0 and under primary_source before it, and mason's own reader branches on exactly that. Read every shape the tool still reads, whatever the floor says.

• cli_names: tuple of binary names to search for. Defaults to (lowercase_class_name,). Set explicitly when the binary name differs from the class name (e.g., cli_names = ("nix-env",) for class Nix).

• version_regexes: tuple of regex strings with a (?P<version>...) named group.

• version_cli_options: tuple of args to get version. Defaults to .

Operations

Each operation maps to one of these methods. Implement as many as the manager supports. Unimplemented operations are automatically skipped by mpm.

Operation	Method signature	Returns	Notes
Installed	installed (property)	Iterator[Package]	Yield packages with id and installed_version.
Outdated	outdated (property)	Iterator[Package]	Yield packages with id, installed_version, and latest_version.
Search	search(query, extended, exact)	Iterator[Package]	Decorate with @search_capabilities(extended_support=..., exact_support=...). Yield with id, latest_version, optionally description.
Install	install(package_id, version=None)	str	Decorate with @version_not_implemented if version pinning is unsupported.
Upgrade all	upgrade_all_cli()	tuple[str, ...]	Return self.build_cli(...), not self.run_cli(...).
Upgrade one	upgrade_one_cli(package_id, version=None)	tuple[str, ...]	Same as above. Decorate with @version_not_implemented if needed.
Remove	remove(package_id)	str	Optional.
Sync	sync()	None	Optional. For refreshing package metadata from remote sources.
Cleanup	cleanup()	None	Optional. For garbage collection, cache clearing, orphan removal.

Key helpers from the base class:

• self.run_cli(*args, **kwargs) executes the manager CLI and returns stdout.
• self.build_cli(*args) builds a command tuple without executing it (used by upgrade_all_cli and upgrade_one_cli).
• self.package(id=..., ...) creates a Package with manager_id pre-filled.
• self.cli_path resolves to the discovered binary path. Use .parent to find sibling binaries for operations that use a different CLI (see nix.py for sync and cleanup).

Delegating operations to another manager

When a manager uses its own CLI for read operations but delegates mutating operations to another manager's binary, use the Delegate descriptor from capabilities.py:

from ..capabilities import Delegate
from .scoop import Scoop


class SFSU(PackageManager):
    _scoop = Delegate(Scoop)

    # Read operations use sfsu's own CLI with JSON output.
    @property
    def installed(self) -> Iterator[Package]:
        output = self.run_cli("list", "--json")
        ...

    # Mutating operations delegate to scoop.
    install = _scoop.install
    upgrade_all_cli = _scoop.upgrade_all_cli
    upgrade_one_cli = _scoop.upgrade_one_cli
    remove = _scoop.remove

The Delegate factory resolves the target manager's CLI binary via self.which() and temporarily sets _delegate_cli_path on the instance so that build_cli routes the command through the target binary. The host manager's post_args are automatically suppressed during delegation.

Place _scoop = Delegate(Scoop) at the top of the class body (before homepage_url). Place individual delegation assignments (install = _scoop.install) in the canonical operation order, interspersed with the other operations.

Do not subclass when the two managers have completely different output formats for read operations. Subclassing is for managers that share the same CLI interface. Delegation is for managers that share the same package ecosystem but have different CLIs.

CLI output guidelines

• Use --long-form-options for self-documenting CLIs.
• Suppress colors and emoji (--no-color, --color=never, etc.) via post_args or extra_env.
• Prefer machine-readable output (JSON, XML, CSV) over text parsing. When parsing text, use class-level compiled regexes with named groups.
• Include at least one CLI output sample in each method's docstring as a .. code-block:: shell-session block. This helps future maintainers verify parsing without access to the actual manager.
• Read {doc}/falsehoods to anticipate edge cases in package naming and versioning.

Choosing the destructive-test package (PACKAGE_IDS)

The destructive suite runs mpm --<id> install <pkg> then mpm --<id> remove <pkg> against the real host, so PACKAGE_IDS[<id>] in tests/conftest.py must name a package that installs and uninstalls cleanly:

• Tiny and fast: no dependency tree, no services/daemons, no /etc config, a single self-contained binary.
• Not relied upon: avoid ubiquitous tools (wget, curl, git, jq, openssl). They are usually already installed (so the install step is a no-op) and removing them can break the host or the test runner.
• Self-contained, ideally a Rust or Go binary.
• Verified to exist in that manager's repo/registry, with the exact ID format the manager expects (a bare name, category/name, bucket/name, Publisher.Package, a numeric ID, ...). Check the real index before committing the choice: do not guess.

Reuse the established picks for consistency instead of inventing new ones:

Ecosystem	Package	Notes
Linux distros, Homebrew, FreeBSD (apt, dnf, pacman, apk, brew, ...)	nyancat	Single-file C binary in nearly every distro, Homebrew and FreeBSD; zero reverse-deps.
Distros lacking nyancat	sl (Solus, Void), hello, lolcat (OpenWrt)	Fall back only where nyancat is absent.
Source-compiling managers (emerge, FreeBSD ports)	games-misc/nyancat, net/nyancat	Compiles in seconds from one C file; use the category/name atom.
Functional managers (Guix, Nix)	hello	The canonical GNU demo package.
Windows binary stores (choco, scoop, sfsu, winget) and stew	hyperfine	One self-contained Rust binary; use the manager's ID format.
npm, Yarn	ms	Zero-dependency, ~7 KB.
pip, uv	pytz	Pure-Python, zero-dependency.
pipx, uvx	pycowsay	Must expose a console-script entry point (a library like pytz fails here).
gem, cpan, composer	paint, Try::Tiny, ralouphie/getallheaders	Smallest inert zero-dependency package native to the language.

Special cases: managers that only ship large artifacts use their lightest option (sdkman → jbang); managers with no real per-package install reference themselves (deb-get, topgrade); fwupd must never use an ID that flashes firmware on real hardware. Add a short inline comment for any non-obvious ID (numeric App Store/Steam IDs, firmware GUIDs).

File checklist

Every new manager touches the same set of files. This list is derived from all 30 manager-addition commits in the project history.

Always required

File	Change
meta_package_manager/managers/<name>.py	The new manager implementation.
meta_package_manager/pool.py	Add import (sorted by module name) and class to manager_classes tuple (sorted case-insensitively by class name).
tests/conftest.py	Add "<manager_id>": "<package_id>" to PACKAGE_IDS. See Choosing the destructive-test package for the selection criteria and the canonical per-ecosystem picks. A missing entry aborts collection of the whole suite (PACKAGE_IDS is asserted against the pool at import time).
tests/test_pool.py	Increment both count assertions in test_manager_count().
changelog.md	Add - [<manager_id>] Add <Name> package manager with <operations> support. under the current unreleased version.
readme.md	Sankey + matrix: mirror-src blocks via refresh-directives. Footnotes: docs_update.py.
docs/managers/<manager_id>.md	Regenerated by docs/docs_update.py: one page stub per pool manager, its sections rendering live at Sphinx build time. Nothing to hand-edit (test_manager_stubs_in_sync enforces byte-identity).
docs/meta_package_manager.managers.md	Add automodule section for meta_package_manager.managers.<name> in alphabetical order.
docs/stars_update.py	Add the manager's upstream repository to UPSTREAM_REPOS, or its reason for having none to NO_UPSTREAM. test_manager_upstreams_cover_the_pool requires every wrapped manager to sit in exactly one of the two, since the pair feeds the popularity and activity columns of the manager index.
docs/cooldown.md	Two hand-maintained tables, each needing a row. The Supported managers table takes the manager's cooldown status ( unless the tool has a release-age gate of its own), and reuses that row on the manager's own page, so omitting it silently drops the section. The table takes the manager's id in whichever registry row its packages come from; fails until it is there, since the mapping must partition the pool.

When applicable

File	When	Change
.github/workflows/tests.yaml	Manager can be installed on CI runners.	Add an install step for every matrix OS the manager's platforms covers, near related managers. Availability stops being the test once a requirement floor is set: check the version each channel ships, and never stop at the distro package, which is the stalest channel there is. Ubuntu 26.04 has Neovim 0.11.6, under vim-pack's >=0.12.0, while the nvim snap, Chocolatey and Scoop all track 0.12.x: reading apt alone is what left vim-pack tested on macOS only, for a manager declaring ALL_PLATFORMS. A platform left out is silent, never red — mpm reports the manager unavailable and its destructive test skips.
docs/benchmark.toml	Manager already appears in the comparison table.	Delete its homepages entry: the homepage now comes from the class (a sync test enforces the set).
docs/assets/managers/	Manager declares a logo whose slug is not vendored yet.	Run python docs/logos_update.py to fetch the mark and refresh logos.yaml. Never hand-edit either: the SVG is normalized and the manifest feeds the credits block of {doc}/license. Commit the SVG itself, not just the manifest: it arrives as a brand-new file, so it is the one artifact a git commit -- <paths> silently leaves behind, and a manifest naming artwork that is not in the tree renders nothing on a fresh checkout while passing every check locally.
.github/workflows/tests-install.yaml + docs/install.md	Manager is a distributor of mpm itself (like Homebrew, Scoop, Nix, or an AUR helper). Most managers are not.	Add a CI job testing mpm installation via the new channel, and a matching tab in the install docs.

Validate

$ uv run -- pytest tests/test_pool.py tests/test_managers.py -x -q
$ uv run --group typing mypy meta_package_manager/managers/<name>.py

The test suite enforces: valid ID format, homepage URL, platform declarations, version regexes, no duplicate IDs, correct pool count, canonical attribute ordering (test_content_order), and label group disjointness.

Common validation failures after adding a manager:

• test_manager_count: forgot to increment the count in test_pool.py.
• test_content_order: class attributes are not in the canonical order (like version_regexes before post_args).
• test_manager_logos_resolve (in tests/test_docs.py, so the Validate command above does not catch it): a declared logo slug with no vendored SVG, or a vendored mark no manager claims. Run docs/logos_update.py.
• Label group collision: the group name in labels.py collides with a manager ID. Use the -based suffix (like scoop-based, pypi-based).
• A content rule silently disappearing: MANAGER_CONTENT_KEYWORDS is keyed by the ID a label derives from, so folding a manager into a group (or renaming one) orphans its entry, which then generates nothing. No test catches it. Re-key it to the group and diff pyproject.toml for a dropped patterns = line.
• Whole-suite collection abort: tests/conftest.py asserts PACKAGE_IDS covers exactly the class managers at import time; a missing class entry (or a stray bundled one) kills every test, not one.
• test_docstring_corpus: the $ ... shell-session samples in operation docstrings are checked against the real CLI construction. Write them in build order: binary, pre_args, the declared arguments with the package ID exactly where the code puts it, post_args last (pkcon install --noninteractive hello --plain, not pkcon install hello --noninteractive --plain).
• test_new_package_manager_issue_template: the issue template's platform checklist is generated from MAIN_PLATFORMS; it goes stale when an extra-platforms release adds detections.