pixi¶
- ID
pixi- Home page
- 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
- Source
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 |
With |
|---|---|---|
List what’s installed |
|
|
Install a package |
|
|
Upgrade one package |
|
|
Upgrade everything |
|
|
Remove a package |
|
|
Clear caches |
|
|
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 |
|---|---|
|
✓ |
|
|
|
|
|
|
|
✓ |
|
✓ |
|
✓ |
|
✓ |
|
|
|
✓ |
|
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, thenmpm restore pixi.tomlon the next one.Export a compliance SBOM:
mpm --pixi sbom(CycloneDX by default,--spdxfor 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 forpixi global)Mechanism:
exclude-newerinpixi.toml, declarative only: no flag, no environment variableReference: 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 thebrokenlabel carried inlabels(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:condaandpkg:nugetpurl 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:condanow fans out tocondaandpixi, andpkg:nugetreachesdotnet.Add the pixi global tool manager with
installed,install,upgrade,removeandcleanupsupport. Packages are keyed on the global environment, the unitpixi global uninstallandpixi global updateaddress, and the version is read from the dependency the environment is named after.