`meta_package_manager.managers.pixi` module¶

class meta_package_manager.managers.pixi.Pixi[source]¶

Bases: PackageManager

pixi installs conda packages, either into a project workspace or machine-wide as global tools.

mpm is system-scoped, so this wrapper drives the pixi global scope alone and never touches a pixi.toml workspace. Global tools resolve from conda channels, conda-forge by default, and land in their own prefix under $PIXI_HOME.

Documentation: pixi global tools.

Important

pixi isolates each global tool in its own environment, and mpm keys packages on the environment name, not on the conda package names inside it. The environment is the unit every mutating pixi global verb addresses: uninstall deletes one whole environment and update refreshes one whole environment, neither taking a package name. pixi global install <pkg> names the environment after the package, so for everything mpm installs the two are the same string and every operation round-trips.

Keying on the inner dependencies instead was tried and is unsafe: it reports packages that remove cannot address one at a time, so removing one of them deletes the whole environment and silently takes its siblings with it.

Caution

An environment holding more than the package it is named after, built with pixi global install <pkg> --with <other> or pixi global add, is therefore reported as the single package <pkg>. Its extra packages are invisible to mpm, and removing <pkg> destroys them along with the environment, which is exactly what a bare pixi global uninstall <pkg> does. mpm neither widens nor narrows that behavior.

Note

An environment whose dependencies do not include the package it is named after reports no version. That is the same signal pixi’s own listing gives: it prints <name>: <version> inline only while the environment resolves to its eponymous package, and drops the version once the contents diverge.

Caution

No search operation is declared, though pixi search exists. Its --json mode cannot be capped: the flag conflicts_with_all the --limit and --limit-packages options that bound the human view, and outside a workspace pixi falls back to Platform::all() and queries every known conda subdir, roughly thirty of them, which is exactly how mpm runs it. Repodata carries no summary or description either, so the results would be name-only. Declaring nothing lets mpm skip the manager during a search rather than stall on it.

Bounding it means passing --platform, which would put a host-to-conda-subdir mapping in mpm that pixi already owns, and an empty result set is an error rather than an empty document, so reviving search is a deliberate piece of work rather than a one-line addition.

Caution

No outdated operation is declared: nothing in pixi global reports upgradable packages without performing the upgrade. pixi global update has no dry-run mode, and the request for a dedicated command (prefix-dev/pixi#6279) was closed pointing at the workspace-scoped pixi update --dry-run, which does not cover the global scope. upgrade --all is unaffected and maps to the native bare pixi global update.

Note

No sync operation either, despite the name of pixi global sync: that command reconciles installed environments against the manifest, installing and removing to match it, rather than refreshing package metadata from the channels. Mapping mpm sync onto it would make a read-shaped command mutate the machine.

Initialize cli_errors list.

name: str = 'pixi'¶

Return package manager’s common name.

Default value is based on class name.

homepage_url: str | None = 'https://pixi.sh'¶: Home page of the project, only used in documentation for reference.

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='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='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='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 = '>=0.65.0'¶: 0.65.0 is where pixi global list gained the --json flag this wrapper reads (prefix-dev/pixi#5530), and it is the binding floor. Every other operation is far older: install dates to 0.0.4, list to 0.3.0, and uninstall / update to the 0.33.0 rewrite that rebuilt pixi global around its manifest. That same rewrite is why nothing below 0.33.0 would work anyway: pixi global remove meant uninstall back then, and now means removing one dependency from an environment.

pre_args: tuple[str, ...] = ('--color=never', '--no-progress')¶

Both are global options, accepted ahead of any subcommand.

pixi colorizes its listings semantically and draws progress bars while solving. Each turns itself off when the matching stream is not a terminal, but mpm asks explicitly rather than relying on redirection. The version probe runs with auto_pre_args=False and so stays a bare pixi --version.

version_regexes: tuple[str, ...] = ('^pixi\\s+(?P<version>\\S+)',)¶

$ pixi --version
pixi 0.48.0

property installed: Iterator[Package]¶

Fetch installed packages.

The document is an array of environments, each carrying the explicit specs it was created from. Transitive dependencies are not listed, which is what makes this an inventory of tools rather than of everything on disk. Each environment yields exactly one package, keyed on the environment name, and its version is read from the dependency of the same name. A version is null for a package the manifest declares but that is not installed in the prefix, and the optional platform key is omitted unless the environment pins one.

The block below is source-derived: its layout follows pixi’s serde_json::to_string_pretty serialization of GlobalEnvironmentJson, and its values are those of the ripgrep entry in pixi’s own pixi global list reference output.

$ pixi --color=never --no-progress global list --json
[
  {
    "name": "ripgrep",
    "dependencies": [
      {
        "name": "ripgrep",
        "version": "14.1.0"
      }
    ],
    "exposed": [
      {
        "exposed_name": "rg",
        "executable": "rg"
      }
    ]
  }
]

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

Install one package.

The positional argument is a conda MatchSpec, so a version is pinned by appending ==<version> to the name rather than through a flag.

$ pixi --color=never --no-progress global install hyperfine

$ pixi --color=never --no-progress global install hyperfine==1.20.0

Return type:: str

upgrade_all_cli()[source]¶

Generates the CLI to upgrade all packages.

Bare pixi global update updates every environment: there is no --all flag. It also prunes stale environments on the way through.

$ pixi --color=never --no-progress global update

Return type:: tuple[str, ...]

cli_names: tuple[str, ...] = ('pixi',)¶

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 = 'pixi'¶

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.

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

Generates the CLI to upgrade one package.

pixi global update takes environment names and accepts no version at all, so a pinned upgrade is not expressible: mpm warns and upgrades to whatever the channels resolve to.

Routing a pinned upgrade through pixi global install <pkg>==<version> instead was tried and rejected. That verb takes a package spec rather than an environment name, and creates the environment when it is missing, so pinning a package that lives inside a differently-named environment forks a second environment holding a second copy and reports success, leaving the original untouched.

$ pixi --color=never --no-progress global update hyperfine

Return type:: tuple[str, ...]

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.

remove(package_id)[source]¶

Remove one package.

pixi global uninstall removes a whole environment, deleting its prefix outright, which is the counterpart of the pixi global install that created it and matches the unit installed() reports. An environment carrying co-installed extras loses those too.

The sibling pixi global remove is deliberately not used: it drops one dependency from an environment and leaves the environment behind, which would strand an entry mpm still reports as installed.

$ pixi --color=never --no-progress global uninstall hyperfine

Return type:: str

cleanup_cache()[source]¶

Clear pixi’s download caches.

--yes is required: with no cache-type flag, pixi clean cache asks for confirmation on <stdin> and would otherwise block forever under mpm.

$ pixi --color=never --no-progress clean cache --yes

Return type:: None

meta_package_manager.managers.pixi module¶

`meta_package_manager.managers.pixi` module¶