meta_package_manager.managers.vcpkg module¶

class meta_package_manager.managers.vcpkg.VCPKG[source]¶

Bases: PackageManager

C and C++ library manager, covering what it installs machine-wide.

vcpkg has two modes and only one is a package manager in mpm’s sense. In manifest mode it reads a vcpkg.json from a project tree and installs beside it, which is project scope and out of scope here, recorded among the project-scoped ecosystems of Unsupported managers. In classic mode it installs into its own root, shared by everything on the machine, which Microsoft’s own documentation compares to brew or apt. That mode is what this wraps, on the same footing as the runtime managers mpm wraps for what they install globally.

Caution

A package is identified by its full specification, name:triplet, because that is vcpkg’s own unit: the same library built for two triplets is two installations, removed independently.

Warning

A vcpkg binary on PATH is not necessarily a working one. vcpkg is normally cloned and bootstrapped, and a packaged binary with no root configured errors on every operation asking for VCPKG_ROOT to be set. Homebrew ships exactly that, and says so in its own caveats. The failure is loud and self-explanatory rather than silent.

Initialize cli_errors list.

operation_notes: ClassVar = {'search': 'Results are named without a triplet; a bare name resolves against the default triplet at install time.'}¶

Per-operation hints rendered in the Notes column of the manager page’s Operations table.

Keyed by the Operations member name, each value is a single short sentence explaining why the manager lacks the operation, or what makes its implementation partial: the pointer a reader needs to judge whether the gap is one they could help close. Each sentence starts with a capital and closes with a period, and starts on a word rather than a code span, so the cell reads standalone beside its row. A blank cell stays silent: a manager documenting nothing documents no gap.

The full rationale never lives here: it belongs in a comment beside the implementing method (or beside this declaration, for an operation with no method to hang it on), so the sentence on the page stays a hint and the code keeps the story. The class docstring follows the same split: it keeps only what a user needs to run the tool day to day, never how mpm wraps it.

Validated by test_operation_notes, which also checks every key matches a real operation: a key outside the enum’s vocabulary would never reach a page.

name: str = 'vcpkg'¶

Return package manager’s common name.

Default value is based on class name.

homepage_url: str | None = 'https://vcpkg.io'¶

Home page of the project, only used in documentation for reference.

Left unset when the home page is the project’s repository, which repository_url names on its own, and when it is the project’s manual, which documentation_url names. Never inherited, like the other links.

documentation_url: str | None = 'https://learn.microsoft.com/en-us/vcpkg/'¶

Entry point of the project’s own documentation, or None when it has none.

The manual, the documentation site, or the man page of the CLI mpm drives: whichever page a user reads to learn the commands this manager wraps. Listed between homepage_url and repository_url in the links of the manager’s page, so a reader reaching for the tool’s reference finds it in the box of facts rather than in the prose below it.

Left unset where a link would state a fact twice or invent one: a tool documenting itself in its repository alone, whose README repository_url already reaches. A page about the ecosystem rather than the tool does not qualify either.

Where a project’s only site is its manual, that address belongs here and homepage_url stays unset: the slot names what the page is, and a reader reaching for the reference looks under the documentation link.

Never inherited, like every other link: the AUR helpers extending pacman each document themselves.

repository_url: str | None = 'https://github.com/microsoft/vcpkg'¶

Repository holding the project’s code, or None when it has no public one.

Linked from the manager’s documentation page. Also what the weekly metrics sample reads: docs/docs_update.py writes it into the [tool.repomatic.metrics] subjects of pyproject.toml when its forge answers the sampler, through a mirror for a forge that does not.

Never inherited, for the same reason as wikipedia_url: the AUR helpers extending pacman each live in a repository of their own.

wikipedia_url: str | None = 'https://en.wikipedia.org/wiki/Vcpkg'¶

English Wikipedia article about the project, or None when it has none.

Listed last in the links of the manager’s documentation page. The article covers the project that home page names, or is a redirect Wikipedia keeps under the project’s name, landing on the part of a broader article that describes it: Cargo_(software) opens the Cargo section of the Rust article. An article that merely mentions the project does not count, nor does one about a related subject: lazy is a Neovim plugin manager, and the Neovim article is not about it.

Never inherited: the metaclass resets it to None on any class not declaring its own. A subclass often wraps a distinct project, like the six AUR helpers extending pacman, and would otherwise present pacman’s article as its own. Documentation-only, like homepage_url.

platforms: frozenset[Platform] | Group | Platform | Iterable[Platform | Group] = frozenset({Platform(id='almalinux', name='AlmaLinux'), Platform(id='alpine', name='Alpine Linux'), Platform(id='altlinux', name='ALT Linux'), Platform(id='amzn', name='Amazon Linux'), Platform(id='android', name='Android'), Platform(id='arch', name='Arch Linux'), Platform(id='buildroot', name='Buildroot'), Platform(id='cachyos', name='CachyOS'), Platform(id='centos', name='CentOS'), Platform(id='chromeos', name='ChromeOS'), Platform(id='clearlinux', name='Clear Linux OS'), Platform(id='cloudlinux', name='CloudLinux OS'), Platform(id='crux', name='CRUX'), Platform(id='debian', name='Debian'), Platform(id='endeavouros', name='EndeavourOS'), Platform(id='exherbo', name='Exherbo Linux'), Platform(id='fedora', name='Fedora'), Platform(id='generic_linux', name='Generic Linux'), Platform(id='gentoo', name='Gentoo Linux'), Platform(id='guix', name='Guix System'), Platform(id='ibm_powerkvm', name='IBM PowerKVM'), Platform(id='kali', name='Kali Linux'), Platform(id='kvmibm', name='KVM for IBM z Systems'), Platform(id='linuxmint', name='Linux Mint'), Platform(id='macos', name='macOS'), Platform(id='mageia', name='Mageia'), Platform(id='mandriva', name='Mandriva Linux'), Platform(id='manjaro', name='Manjaro Linux'), Platform(id='nixos', name='NixOS'), Platform(id='nobara', name='Nobara'), Platform(id='nutyx', name='NuTyX'), Platform(id='opensuse', name='openSUSE'), Platform(id='openwrt', name='OpenWrt'), Platform(id='oracle', name='Oracle Linux'), Platform(id='parallels', name='Parallels'), Platform(id='pidora', name='Pidora'), Platform(id='pikaos', name='PikaOS'), Platform(id='raspbian', name='Raspbian'), Platform(id='rhel', name='RedHat Enterprise Linux'), Platform(id='rocky', name='Rocky Linux'), Platform(id='scientific', name='Scientific Linux'), Platform(id='slackware', name='Slackware'), Platform(id='sles', name='SUSE Linux Enterprise Server'), Platform(id='slitaz', name='SliTaz GNU/Linux'), Platform(id='solus', name='Solus'), Platform(id='sourcemage', name='Source Mage GNU/Linux'), Platform(id='tuxedo', name='Tuxedo OS'), Platform(id='ubuntu', name='Ubuntu'), Platform(id='ultramarine', name='Ultramarine'), Platform(id='void', name='Void Linux'), Platform(id='windows', name='Windows'), Platform(id='wsl1', name='Windows Subsystem for Linux v1'), Platform(id='wsl2', name='Windows Subsystem for Linux v2'), Platform(id='xenserver', name='XenServer')})¶

List of platforms supported by the manager.

Allows for a mishmash of platforms and groups of platforms. Will be normalized into a frozenset of Platform instances at instantiation.

requirement: str | None = None¶

No floor, because vcpkg’s version is a release date rather than a semantic version and a requirement here is written in digits and comparisons alone, which a hyphenated date cannot be.

Nothing is lost by it. Every interface used here shipped alongside manifest mode in 2020, so no release a user could plausibly be running lacks them, and a floor could not catch the case that would matter anyway: a locally built vcpkg reports a sentinel date far in the future precisely so that version checks in scripts always pass.

pre_args: tuple[str, ...] = ('--classic',)¶

Pins every call to the machine-wide installation, whatever the working directory contains.

version_regexes: tuple[str, ...] = ('version (?P<version>\\d{4}-\\d{2}-\\d{2})',)¶

Search the release date the version banner reports.

$ vcpkg --classic version
vcpkg package management program version 2026-07-27-unknownhash

See LICENSE.txt for license information.

The trailing component is a commit hash, or a packager’s own marker, and is dropped.

property installed: Iterator[Package]¶

Fetch installed packages.

$ vcpkg --classic list --x-json
{
  "zlib:x64-linux": {
    "package_name": "zlib",
    "triplet": "x64-linux",
    "version": "1.3.1",
    "port_version": 0,
    "features": [],
    "desc": ["A compression library"]
  }
}

The port revision is appended to the version as vcpkg itself renders it, and only when it is not zero.

property outdated: Iterator[Package]¶

Fetch outdated packages.

vcpkg’s update is a report rather than a mutation: in classic mode it compares what is installed against the ports catalog and prints the difference, changing nothing. It refuses to run in manifest mode at all, which the forced --classic keeps it out of.

$ vcpkg --classic update
Using local port versions. To update the local ports, use ``git pull``.
The following packages differ from their port versions:
        corrade:x64-windows              2020.06#4 -> 2020.06#5
        openal-soft:x64-windows          1.22.2#5 -> 1.23.0
cli_names: tuple[str, ...] = ('vcpkg',)¶

List of CLI names the package manager is known as.

This list of recognized CLI names is ordered by priority. That way we can influence the search of the right binary.

..hint::

This was helpful in the case of the Python transition from 2.x to 3.x, where multiple versions of the same executable were named python or python3.

By default, this property’s value is derived from the manager’s ID (see the MetaPackageManager.__init__ method above).

id: str = 'vcpkg'¶

Package manager’s ID.

Derived by defaults from the lower-cased class name in which underscores _ are replaced by dashes -.

This ID must be unique among all package manager definitions and lower-case, as they’re used as feature flags for the mpm CLI.

search(query, extended, exact)[source]¶

Fetch matching packages.

Read as JSON, whose keys are the port names. The human listing computes its column widths from the results and renders a port’s features as rows of their own carrying no version, neither of which a single pattern reads reliably.

Caution

Search does not support extended or exact matching.

Caution

--x-json is experimental, as its x prefix announces, and a vcpkg predating it ignores it silently rather than refusing it: the command succeeds and prints the human column listing instead. Decoding that as JSON raises, and nothing isolates one manager’s failure from the rest of a fan-out, so an unhandled decode error would take down the entire mpm search on any host carrying such a build. A version floor cannot catch it, vcpkg numbering its releases by date, as requirement explains, so the column listing is parsed instead when the JSON does not decode.

The fallback matters beyond search: install picks its manager by searching first, so a vcpkg whose search answers nothing can install nothing either.

$ vcpkg --classic search excel --x-json
cpr                      1.14.2           C++ Requests is a simple wrapper around libcurl
cpr[ssl]                                  Enable SSL support
duckdb[excel]                             Statically link the excel extension into DuckDB
freexl                   2.0.0#2          FreeXL is an open source library to extract valid data
Return type:

Iterator[Package]

virtual: bool = False¶

Should we expose the package manager to the user?

Virtual package manager are just skeleton classes used to factorize code among managers of the same family.

install(package_id, version=None)[source]¶

Install one package.

A bare name resolves against the default triplet; a full specification pins the one it names.

$ vcpkg --classic install zlib:x64-linux
Return type:

str

upgrade_all_cli()[source]¶

Generates the CLI to upgrade all packages.

--no-dry-run is required for vcpkg to act at all: without it the command prints its plan, warns, and exits non-zero.

$ vcpkg --classic upgrade --no-dry-run
Return type:

tuple[str, ...]

upgrade_one_cli(package_id, version=None)[source]¶

Generates the CLI to upgrade the package provided as parameter.

$ vcpkg --classic upgrade --no-dry-run zlib:x64-linux
Return type:

tuple[str, ...]

remove(package_id)[source]¶

Removes a package.

--recurse is deliberately not passed. vcpkg refuses to remove a package other installations depend on, listing them and exiting non-zero, and that refusal is the right outcome: the alternative would quietly remove packages the user never named.

$ vcpkg --classic remove zlib:x64-linux
Return type:

str