pixi

ID

pixi

Home page

https://pixi.sh

Version requirement

>= 0.65

Platforms

🐧 Linux · 🍎 macOS · 🪟 Windows

Operations

installed · install · upgrade · upgrade_all · remove · cleanup

purl types

pkg:conda · pkg:pixi

CLI name

pixi

Every call

pixi --color=never --no-progress <command>

Issues and PRs

📦 manager: conda-based

Source

meta_package_manager/managers/pixi.py

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.

What mpm adds to pixi

mpm reaches across every manager at once, not pixi alone: mpm installed and mpm outdated cover pixi alongside conda and any other manager you run in one table, mpm upgrade --all updates them together, and mpm sbom exports the whole machine as one bill of materials.

Every mpm command also gains --dry-run and --plan previews, cross-scheme version comparison and purl identifiers. See manager augmentations for how each one is built.

Your pixi commands, in mpm

You already know pixi: each operation maps one-to-one onto mpm, in an interface shared by every manager.

To…

With pixi

With mpm

List what’s installed

pixi global list --json

mpm --pixi installed

Install a package

pixi global install hyperfine

mpm install pkg:pixi/hyperfine

Upgrade one package

pixi global update hyperfine

mpm --pixi upgrade hyperfine

Upgrade everything

pixi global update

mpm --pixi upgrade --all

Remove a package

pixi global uninstall hyperfine

mpm remove pkg:pixi/hyperfine

Clear caches

pixi clean cache --yes

mpm --pixi cleanup --cache

Prefix any command above with --dry-run to simulate the underlying manager calls without touching the system: the safe way to watch what mpm would do before trusting it.

Operations

Operation

Supported

installed

outdated

orphans

search

install

upgrade

upgrade_all

remove

sync

cleanup

doctor

Selecting and configuring pixi

Deselect pixi for a single run with --no-pixi, or persist the choice in your configuration:

[mpm]
pixi = false

The arguments and environment variables listed in the box atop this page are forced on every pixi call, so runs stay quiet, non-interactive and reproducible: the defaults you would set in CI anyway.

Keep it enabled but tune how mpm drives it with a per-manager override:

[mpm.managers.pixi]
timeout = 900

mpm config-template pixi prints every overridable attribute as a ready-to-paste block.

Recipes

A few jobs you would otherwise script around pixi, one mpm command each:

  • Snapshot and clone a machine: mpm --pixi dump pixi.toml, then mpm restore pixi.toml on the next one.

  • Export a compliance SBOM: mpm --pixi sbom (CycloneDX by default, --spdx for SPDX).

Privilege escalation

mpm runs this manager as the current user and never prepends sudo by default. Flip the policy for its privileged operations with --sudo or the per-manager sudo override.

See privilege escalation for the full policy.

Cooldown

State of pixi’s release-age gating, from the cooldown support table:

  • Status: 🚧 Proposed (shipped for workspaces since 0.47.0, never for pixi global)

  • Mechanism: exclude-newer in pixi.toml, declarative only: no flag, no environment variable

  • Reference: prefix-dev/pixi#5810

A cooldown only pays off where a compromised release can be withdrawn while the clock runs, and can only be emulated where the registry dates its releases. From the retraction table:

  • Registry: anaconda.org / conda-forge (pkg:conda)

  • Retraction: Relabel: “we do not allow edits or the deletion of packages on conda-forge” (immutability); a bad artifact is labelled broken and “Users will no longer be able to install them by default” (procedure)

  • Publish date: ✅ upload_time, with the broken label carried in labels (API)

With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --allow-unsupported-managers opts back in.

Version probe

The version is probed by running:

$ pixi --version
pixi 0.48.0

and extracted with:

r"^pixi\s+(?P<version>\S+)"

Reference traces

Raw native outputs captured in the manager source: the reference mpm’s parsers were written against. If you know pixi well and a transcript below looks wrong, or a newer release changed its output format, report it.

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

Feed any of these through mpm and the raw output becomes one uniform table, the same shape for every manager: filter it, project columns, or export it (mpm --pixi installed --output json, or csv, toml, yaml), each package carrying a purl and a version comparable across managers.

Changelog

  • 7.7.0.dev0 (unreleased)

    • Resolve the pkg:conda and pkg:nuget purl types, which both raised instead of routing: a type declared with no manager short-circuits the fallback that would otherwise match it against the manager IDs. pkg:conda now fans out to conda and pixi, and pkg:nuget reaches dotnet.

    • Add the pixi global tool manager with installed, install, upgrade, remove and cleanup support. Packages are keyed on the global environment, the unit pixi global uninstall and pixi global update address, and the version is read from the dependency the environment is named after.