pipxu

ID

pipxu

Home page

https://github.com/bulletmark/pipxu

Platforms

🐧 Linux · 🍎 macOS

Operations

installed · install · upgrade · upgrade_all · remove

purl types

pkg:pipxu

CLI name

pipxu

Issues and PRs

📦 manager: pypi-based

Source

meta_package_manager/managers/pipxu.toml

pipxu installs Python applications into isolated virtual environments (https://github.com/bulletmark/pipxu), the way pipx does, but building each environment with uv rather than with venv and pip.

A package is the application’s distribution name, and every verb takes it: install, uninstall and upgrade all accept one or more, and the listing prints one per line. It shares PyPI with pip, pipx, uv and uvx, which is why it joins their label group, but its inventory is its own: an application installed through pipxu is invisible to the other four.

Parsing notes, verified against pipxu 1.34 on macOS:

• The inventory is pipxu version, not pipxu list. Both enumerate the installed applications, but list reports the executables each one provides and no version at all, while version prints exactly one name==version per line. list --json is neither: it nests the executables under a name-keyed object and still carries no version.

• pipxu --version and pipxu version are different commands that look alike. The flag prints the tool’s own version, pipxu==1.34, in the very shape a package line takes, so the version probe and the inventory must not be swapped.

• upgrade genuinely restricts itself to the applications it is given, checked against an unknown name rather than assumed: it answers Error: Unknown package and upgrades nothing. That is what makes upgrade_one declarable here where pamac and pkgm refuse it.

• No outdated: nothing reports staleness without acting on it, upgrade resolving and installing in one pass.

• No search and no sync: pipxu has neither, deferring both to the index uv resolves against.

Caution

pipxu exits 0 on a failed operation, an unknown package name included, so an exit code proves nothing about whether the operation did anything.

Note

Upstream supports Linux and macOS only: “This utility has been developed and tested on Linux but will likely also work on macOS. It does not work and is not supported on Windows.” The macOS half of that was verified here.

What mpm adds to pipxu

mpm reaches across every manager at once, not pipxu alone: mpm installed and mpm outdated cover pipxu alongside every 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 pipxu commands, in mpm

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

To…	With pipxu	With mpm
List what’s installed	pipxu version	mpm --pipxu installed
Install a package	pipxu install <package_id>	mpm install pkg:pipxu/<package_id>
Upgrade one package	pipxu upgrade <package_id>	mpm --pipxu upgrade <package_id>
Upgrade everything	pipxu upgrade --all	mpm --pipxu upgrade --all
Remove a package	pipxu uninstall <package_id>	mpm remove pkg:pipxu/<package_id>

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 pipxu

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

[mpm]
pipxu = false

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

[mpm.managers.pipxu]
timeout = 900

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

Recipes

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

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

• Export a compliance SBOM: mpm --pipxu 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.

None of its operations needs root.

See privilege escalation for the full policy.

Cooldown

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

Status: ❌ None (no release-age knob; uv gains one only through its own env)

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: PyPI (pkg:pypi)

• Retraction: Yank (PEP 592): the file stays downloadable, but an installer “MUST ignore yanked releases, if the selection constraints can be satisfied with a non-yanked version”

• Publish date: ✅ upload_time_iso_8601, plus a per-file yanked flag (JSON API)

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

Version probe

The version is probed by running:

$ pipxu --version
pipxu==1.34

and extracted with:

r"pipxu==(?P<version>\S+)"

Reference traces

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

$ pipxu version
pycowsay==0.0.0.2

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 --pipxu installed --output json, or csv, toml, yaml), each package carrying a purl and a version comparable across managers.

Changelog

• 8.0.0.dev0 (unreleased)

  • Add pipxu package manager, with inventory, install, remove and upgrade support.