ixt vs the alternatives¶

tl;dr — ixt is the only tool that manages Python, Node, and GitHub binaries with per-tool isolation and a single declarative config.

Comparison¶

Day-one — install a tool the day it ships its first GitHub release, without any formula, registry entry, or plugin.

No system runtime needed — ixt is pure Python stdlib. Runtimes (uv, bun) are auto-bootstrapped on first use; you don't need Node, npm, or any package manager pre-installed.

Tool-by-tool¶

pipx — Python only¶

pipx does one thing well: install Python CLI tools in isolated venvs. If you only manage Python tools, pipx is a fine choice. ixt is its natural evolution if you also need npm CLIs or GitHub binaries — same isolation model, three ecosystems.

aqua — binaries, but registry-gated¶

aqua is declarative and reproducible, with a large community registry. The catch: every tool must have an entry in aqua-registry. A tool released yesterday isn't installable until someone submits a PR. ixt's heuristics cover most release conventions out of the box.

mise — runtimes first, tools second¶

mise is excellent for managing language runtimes (Python versions, Node versions) per project. Its tool support via backends is broad but requires plugins for anything outside its built-in list. ixt focuses exclusively on tools and bootstraps runtimes transparently without managing them.

ubi — binaries, day-one, no declarative config¶

ubi is the closest in spirit to ixt's binary backend: heuristic-based GitHub asset selection, works on new tools immediately. What it lacks: Python and Node support, per-tool isolation, and a declarative config file. Think of ubi as ixt's binary backend extracted as a standalone tool.

Homebrew — everything, but shared and slow¶

Homebrew covers all ecosystems but puts everything in a shared cellar — no per-tool isolation, dependency conflicts are real. Adding a new tool requires a formula PR that goes through review. Fine for a personal Mac; a liability for reproducible CI environments.

Use cases where ixt shines¶

New machine, ready in two commands¶

ixt setup path          # add $IXT_HOME/installed/bin to PATH
ixt tool apply               # install everything declared in ixt.toml

One ixt.toml covers your Python linters, npm CLIs, and Rust/Go binaries. No separate pipx commands, no npm -g, no brew commands.

Tool released this morning¶

A new Rust tool just published its first GitHub release:

ixt tool install someorg/brand-new-tool    # works immediately

No formula PR. No registry entry. No plugin to write. The heuristics pick the right asset.

Pinned CI across ecosystems¶

# ixt.toml — committed to the repo
[tools]
"@pypi:ruff"          = { version = "==0.9.0" }  # Python linter
"@pypi:mypy"          = { version = "==1.11.0" } # Python type checker
"@npm:@biomejs/biome" = { version = "==1.9.4" }  # Node formatter
"@gh:sharkdp/fd"      = { version = "==10.2.0" } # Rust binary

ixt lock check
ixt tool apply --locked --strict --remove --yes

Single config, generated lock, three ecosystems. Exact pins and ixt.lock give repeatable installs; --locked --strict fails early when ixt.toml and ixt.lock diverge.

Node tool on a machine without Node¶

ixt tool install @anthropic-ai/claude-code

bun is bootstrapped automatically on first Node install — no Node, no npm, no nvm needed on the host.

Two versions of the same tool, side by side¶

ixt tool install ruff                                  # exposed as `ruff`
ixt tool install ruff==0.5.7 --slot ruff-old --bare
ixt tool config ruff-old expose ruff:ruff-old          # exposed as `ruff-old`

Both on PATH simultaneously, no conflicts.

Full recipe