Package & Toolchain Managers Arena
uv vs Bun (package manager)
uv
Astral Software Inc.
Bun (package manager) wins · 7–13 (14 drawn)
Agent experience — stories about agent experience in this arenaAgent experience
Stories about agent experience in this arena
Headless installs
ai-native userHave an agent install and update project dependencies non-interactively, with clear exit codes and errors when something fails
weight 3 · round drawnuv's `uv add`, `uv remove`, and `uv lock --upgrade-package` commands are documented as non-interactive CLI operations that update the lockfile/environment, and community reports confirm uv surfaces resolution errors (e.g., failing to resolve a local wheel) rather than silently succeeding, supporting scriptable failure detection. However, no evidence explicitly documents uv's exit-code conventions or structured/machine-parseable error output for agent-driven automation. Missing for 10: explicit exit-code documentation, structured/JSON error reporting, and first-party guidance on non-interactive/CI failure handling.
- [claimed-docs] “You can add dependencies to your `pyproject.toml` with the `uv add` command. This will also update the lockfile and project environment”
- [claimed-docs] “To remove a package, you can use `uv remove`”
- [claimed-docs] “To upgrade a package, run `uv lock` with the `--upgrade-package` flag”
- [community] “I have one problem with uv... It doesn't seem to understand the concept of >= when it's trying to resolve a local wheel I built and use... i…”
- [claimed-docs] “The `--upgrade-package` flag will attempt to update the specified package to the latest compatible version, while keeping the rest of the lo…”
Bun install is scriptable and non-interactive by default (no prompts documented), supports --frozen-lockfile for reproducible CI installs, and errors out when a required dependency isn't cached (bun-docs-5, bun-docs-20, bun-docs-35). However, docs never explicitly discuss exit-code semantics or structured error output for agent consumption, and community reports note install crashes/bugs under certain conditions (bun-comm-7), suggesting real-world reliability caveats. missing for 10: explicit exit-code documentation, structured/parseable error output, independent verification that failures are cleanly reported rather than crashing.
- [claimed-docs] “Never touch the network (registry, tarball URLs, git); a required dependency that is not cached is an error”
- [claimed-docs] “a required dependency that is not cached is an error”
- [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
- [claimed-docs] “To install in production mode (without `devDependencies`):”
- [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
Manifest editing
ai-native userAdd, remove, and upgrade dependencies through CLI commands that safely rewrite the manifest and lockfile, so an agent never hand-edits them
weight 2 · round to uvuv provides dedicated CLI commands (`uv add`, `uv remove`, `uv lock --upgrade-package`) that programmatically update both pyproject.toml and uv.lock, exactly the kind of safe manifest/lockfile rewrite an agent would invoke instead of hand-editing files, and this is corroborated by community reports of uv 'just working' for dependency management. missing for 10: no explicit hands-on evidence of an agent-driven workflow using these commands, and no discussion of safety guarantees against manual lockfile edits.
- [claimed-docs] “You can add dependencies to your `pyproject.toml` with the `uv add` command. This will also update the lockfile and project environment”
- [claimed-docs] “The `--upgrade-package` flag will attempt to update the specified package to the latest compatible version, while keeping the rest of the lo…”
- [claimed-docs] “To remove a package, you can use `uv remove`”
- [claimed-docs] “To upgrade a package, run `uv lock` with the `--upgrade-package` flag”
- [claimed-docs] “`uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [community] “UV is fast, like FAST. Plus, it removes the need for pyenv and pip for me... no need to activate env or anything, uv run automatically runs …”
- [community] “The biggest praise I can give uv is that as a non Python dev, it makes Python a lot more accessible... With uv, you don't have to care about…”
Docs confirm bun install writes package.json/bun.lock automatically, migrates other lockfiles, supports --frozen-lockfile for reproducible installs, and never touches network beyond cache (docs-2,5,35,38), which is exactly the safe manifest/lockfile-rewrite behavior an agent needs instead of hand-editing. Missing for 10: explicit doc citations for the `bun add`, `bun remove`, and `bun upgrade` subcommands themselves (only `bun install` and `bun pm` are directly quoted), and no independent/hands-on evidence specifically validating add/remove/upgrade correctness.
- [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles: `yarn.lock` (v1), `package-lock…”
- [claimed-docs] “Never touch the network (registry, tarball URLs, git); a required dependency that is not cached is an error”
- [claimed-docs] “Bun does not execute arbitrary lifecycle scripts like `postinstall` for installed dependencies. Executing arbitrary scripts represents a pot…”
- [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
- [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
- [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”
Structured output
ai-native userGet machine-readable (JSON) output from core commands so an agent can parse results instead of scraping text
weight 2 · round to uvDocs show at least one core command supporting machine-readable output (`uv version --output-format json`), indicating uv has JSON output support for some commands, which an agent could parse instead of scraping text. However, evidence pack shows only this single command with a JSON flag; there's no documentation of JSON output across other core commands (uv add, uv lock, uv tree, uv pip list, uv tool list, etc.) or independent confirmation of consistent structured-output support. Missing for 10: JSON/structured output evidence for other core commands (add, remove, lock, tree, pip list/freeze), a documented schema, and independent/hands-on confirmation that agents can reliably parse it.
- [claimed-docs] “$ uv version --output-format json”
Bun (package manager)none0/10No evidence in the pack shows any Bun package-manager command (install, pm ls, audit, outdated, pack, etc.) offering a --json or machine-readable output flag; docs only describe human-readable text output and lockfile formats. No JSON/agent-parseable output capability is documented.
ai-native userPoint an agent at a documented, text-based lockfile format it can read and diff
weight 1 · round to Bun (package manager)uv.lock is documented as a well-defined, cross-platform lockfile containing exact dependency information, and uv provides a documented CLI/reference and llms.txt for machine consumption, supporting agent readability. However, the evidence never explicitly states the lockfile's text format (TOML) or its diff-friendliness, nor is there community/hands-on confirmation of agents reading/diffing uv.lock. Missing for 10: explicit documentation of the lockfile's text/TOML format, explicit diff-friendliness claims, and independent evidence of agents successfully parsing or diffing uv.lock.
- [claimed-docs] “`uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv publishes an llms.txt index of its documentation at docs.astral.sh/uv/llms.txt (served as text/plain): "# uv > uv is an extremely fast Py…”
- [probe] “official CLI documented at https://docs.astral.sh/uv/reference/cli/”
Bun's default lockfile format bun.lock is explicitly text-based (v1.2+) and documented, replacing the binary bun.lockb, and docs market it as 'a lockfile you can read'—directly matching the story of a documented, diffable, text lockfile an agent could parse. Missing for 10: no independent/hands-on confirmation of agent tooling actually diffing bun.lock or third-party validation of its readability/diff-friendliness beyond vendor docs.
- [claimed-docs] “Bun v1.2 changed the default lockfile format to the text-based `bun.lock`.”
- [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
- [claimed-docs] “npm-compatible, up to 30× faster. Workspaces, catalogs, overrides, patches and a lockfile you can read.”
- [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles”
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to Bun (package manager)uv explicitly publishes an llms.txt index at docs.astral.sh/uv/llms.txt and exposes every doc page as raw markdown via an index.md suffix, directly enabling agent-oriented doc consumption. The probe evidence checked different, incorrect paths (root-level llms.txt, bare .md suffix) so it does not actually contradict the documented llms.txt location. Missing for 10: independent/hands-on confirmation that the exact documented llms.txt URL and index.md convention work as described.
- [claimed-docs] “uv publishes an llms.txt index of its documentation at docs.astral.sh/uv/llms.txt (served as text/plain): "# uv > uv is an extremely fast Py…”
- [probe] “PROBE llms.txt: HTTP 404 at https://docs.astral.sh/llms.txt”
- [probe] “PROBE docs-md: HTTP 404 at https://docs.astral.sh/uv/.md”
Bun ships a live llms.txt (HTTP 200) plus markdown-rendered docs (docs.md), directly enabling an agent to be pointed at agent-oriented documentation, confirmed via direct probes rather than just claims. missing for 10: no independent/community confirmation that agents actually consume it successfully in practice.
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to uvuv is explicitly designed as a scriptable CLI with deterministic, non-interactive commands (init, add, run, lock, tool install) and provides official CI tooling via the astral-sh/setup-uv GitHub Action, cache persistence for CI, and self-update; it also ships a documented CLI reference and JSON output mode (uv version --output-format json) for machine parsing, all consistent with headless/CI use. Missing for 10: no independent CI-hands-on report confirming smooth headless runs at scale, and community notes mention some friction with Docker/CI env var complexity (uv-comm-16).
- [claimed-docs] “we recommend the official `astral-sh/setup-uv` action, which installs uv, adds it to PATH, (optionally) persists the cache, and more”
- [claimed-docs] “we recommend the official [`astral-sh/setup-uv`](https://github.com/astral-sh/setup-uv) action, which installs uv, adds it to PATH, (optiona…”
- [claimed-docs] “When using a matrix to test multiple Python versions, set the Python version using `astral-sh/setup-uv`”
- [claimed-docs] “This will respect the Python version pinned in the project.”
- [claimed-docs] “$ uv version --output-format json”
- [github] “uv can update itself to the latest version: bash uv self update ”
- [community] “1. It tries to do too many things... 2. You end up needing to use `uv pip` so it's not even a full replacement for pip. 3. It does not play …”
Bun's CLI supports scriptable, non-interactive flags like --frozen-lockfile for reproducible installs, production mode installs, and global cache usage, which are all suitable for CI pipelines, and its speed claims are documented for automation contexts. However, there is no explicit CI/headless documentation, no GitHub Actions examples, no CI exit-code/error-handling docs, and community evidence shows real-world install flakiness in CI-like conditions (crashes, lockfile issues). missing for 10: explicit CI/headless usage docs or examples, GitHub Actions/official CI integration guide, evidence of stable non-interactive automation behavior, and independent corroboration of headless reliability in pipelines.
- [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
- [claimed-docs] “To install in production mode (without `devDependencies`):”
- [claimed-docs] “Bun stores every package downloaded from the registry in a global cache at `~/.bun/install/cache`”
- [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
- [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”
ai-native userUse an official CLI
weight 2 · round drawnuv ships an official, extensively documented CLI (docs.astral.sh/uv/reference/cli/) covering project management, tool execution, packaging, and even JSON-structured output (`uv version --output-format json`) suitable for scripting/agentic use, corroborated by extensive first-party docs and independent hands-on community reports of CLI usage. Missing for 10: no explicit documentation or guide targeting AI-agent/automation-specific CLI usage patterns beyond general scriptability.
- [probe] “official CLI documented at https://docs.astral.sh/uv/reference/cli/”
- [claimed-docs] “$ uv version --output-format json”
- [claimed-docs] “A single tool to replace `pip`, `pip-tools`, `pipx`, `poetry`, `pyenv`, `twine`, `virtualenv`, and more.”
- [claimed-docs] “Runs scripts, with support for inline dependency metadata.”
- [community] “UV is fast, like FAST. Plus, it removes the need for pyenv and pip for me... no need to activate env or anything, uv run automatically runs …”
- [community] “The biggest praise I can give uv is that as a non Python dev, it makes Python a lot more accessible... With uv, you don't have to care about…”
- [claimed-docs] “uv publishes an llms.txt index of its documentation at docs.astral.sh/uv/llms.txt (served as text/plain): "# uv > uv is an extremely fast Py…”
Bun ships an official, extensively documented CLI (bun install, bunx, bun pm, etc.) that is the product's primary interface, and Bun even exposes machine-readable docs (llms.txt, docs.md) explicitly for AI/agent consumption. Community evidence corroborates ergonomic scripting/automation use (comm-8, comm-9). Missing for 10: no first-party documentation of CLI use within specific agent frameworks or automation harnesses beyond anecdotal community reports.
- [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”
- [claimed-docs] “bunx cowsay 'Hello, world!' # execute a package”
- [probe] “PROBE llms.txt: HTTP 200 at https://bun.com/llms.txt # Bun ## Docs - [Welcome to Bun](https://bun.com/docs/index.md): Bun is an all-in-one…”
- [probe] “PROBE docs-md: HTTP 200 at https://bun.com/docs.md # Welcome to Bun > Bun is an all-in-one toolkit for developing modern JavaScript/TypeScr…”
- [probe] “official CLI documented at https://bun.com/docs/cli/install”
- [community] “Really loving Bun these days. Was really pleasantly surprised using their shell scripting API in typescript - single file, shebang line, str…”
- [community] “It is also my first choice now. Especially due to built in SQLite support. Also recently needed to write a simple script to dump some data t…”
ai-native userDrive the product through a documented public API
weight 3 · round drawnuv is a CLI tool whose only 'API' is its command-line interface, which is thoroughly documented (uv-probe-4 CLI reference) and includes some machine-friendly outputs (e.g. `uv version --output-format json`) plus a claimed llms.txt/markdown doc mirror for LLM consumption (uv-docs-52). However there is no true public REST/SDK API, and independent probes found no openapi spec and a 404 on the root llms.txt path (uv-probe-1, uv-probe-3), so AI-native programmatic access is limited to shelling out to the CLI rather than calling a documented API surface. Missing for 10: a genuine REST/SDK API, confirmed working llms.txt/openapi endpoint, and evidence of agents driving uv via anything beyond CLI invocation.
- [probe] “official CLI documented at https://docs.astral.sh/uv/reference/cli/”
- [claimed-docs] “$ uv version --output-format json”
- [claimed-docs] “uv publishes an llms.txt index of its documentation at docs.astral.sh/uv/llms.txt (served as text/plain): "# uv > uv is an extremely fast Py…”
- [probe] “PROBE llms.txt: HTTP 404 at https://docs.astral.sh/llms.txt”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.astral.sh/openapi.json, https://docs.astral.sh/swagger.json, https://docs.astral.sh/api…”
Bun ships extensively documented CLI commands (install, pm, audit, workspaces, etc.) and even exposes machine-readable docs via llms.txt/docs.md that an AI agent could parse to drive it, but there is no formal public API (REST/OpenAPI/SDK) for programmatic control—OpenAPI probes all 404. This is CLI-driven automation, not a genuine API contract for agentic integration. missing for 10: a documented HTTP/OpenAPI or SDK-style API, first-party guidance on programmatic/agent use beyond shell invocation, independent confirmation of AI agents successfully driving it.
- [probe] “PROBE llms.txt: HTTP 200 at https://bun.com/llms.txt # Bun ## Docs - [Welcome to Bun](https://bun.com/docs/index.md): Bun is an all-in-one…”
- [probe] “PROBE docs-md: HTTP 200 at https://bun.com/docs.md # Welcome to Bun > Bun is an all-in-one toolkit for developing modern JavaScript/TypeScr…”
- [probe] “PROBE openapi: all candidate paths 404 (https://bun.com/openapi.json, https://bun.com/swagger.json, https://bun.com/api/openapi.json, https:…”
- [probe] “official CLI documented at https://bun.com/docs/cli/install”
- [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round drawnuvnone0/10uv ships static CLI reference documentation (uv-probe-4) with code-block examples, but there is no interactive, runnable API reference — explicit probes for llms.txt, markdown-doc endpoints, and OpenAPI/Swagger specs all returned 404s (uv-probe-1, uv-probe-2, uv-probe-3), and no evidence describes an interactive playground or executable docs.
- [probe] “PROBE llms.txt: HTTP 404 at https://docs.astral.sh/llms.txt”
- [probe] “PROBE docs-md: HTTP 404 at https://docs.astral.sh/uv/.md”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.astral.sh/openapi.json, https://docs.astral.sh/swagger.json, https://docs.astral.sh/api…”
- [probe] “official CLI documented at https://docs.astral.sh/uv/reference/cli/”
Bun (package manager)none0/10No evidence of an interactive API reference or runnable examples; docs are static markdown pages and OpenAPI/interactive endpoints all 404. Bun is a package manager/runtime, so the axis is a fair question but nothing in the evidence shows an interactive, runnable reference.
- [probe] “PROBE openapi: all candidate paths 404 (https://bun.com/openapi.json, https://bun.com/swagger.json, https://bun.com/api/openapi.json, https:…”
- [probe] “PROBE llms.txt: HTTP 200 at https://bun.com/llms.txt # Bun ## Docs - [Welcome to Bun](https://bun.com/docs/index.md): Bun is an all-in-one…”
- [probe] “PROBE docs-md: HTTP 200 at https://bun.com/docs.md # Welcome to Bun > Bun is an all-in-one toolkit for developing modern JavaScript/TypeScr…”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round drawnuv is a CLI tool without a REST/network API, so a traditional OpenAPI spec doesn't apply, but it does publish a machine-readable llms.txt index and raw markdown for every docs page, which is the closest 'equivalent' to a machine-readable spec of its surface (uv-docs-52). However, dedicated probes for actual OpenAPI/swagger endpoints and root-level llms.txt all returned 404s, showing no formal structured API spec exists (uv-probe-1, uv-probe-2, uv-probe-3). Missing for 10: a structured machine-readable spec of the CLI commands/flags themselves (e.g., JSON schema of the CLI), and confirmation the llms.txt/markdown route is discoverable at a standard well-known path.
- [claimed-docs] “uv publishes an llms.txt index of its documentation at docs.astral.sh/uv/llms.txt (served as text/plain): "# uv > uv is an extremely fast Py…”
- [probe] “PROBE llms.txt: HTTP 404 at https://docs.astral.sh/llms.txt”
- [probe] “PROBE docs-md: HTTP 404 at https://docs.astral.sh/uv/.md”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.astral.sh/openapi.json, https://docs.astral.sh/swagger.json, https://docs.astral.sh/api…”
- [probe] “official CLI documented at https://docs.astral.sh/uv/reference/cli/”
Bun has no REST/HTTP API to describe via a formal OpenAPI spec (it's a local CLI/package manager), but probes confirm it exposes an AI-consumable machine-readable docs equivalent (llms.txt and docs.md) rather than a true OpenAPI/swagger file, which 404s on all standard paths. missing for 10: an actual OpenAPI/swagger spec, any documented API schema, independent confirmation that llms.txt is treated as a valid 'equivalent' by AI tooling.
- [probe] “PROBE llms.txt: HTTP 200 at https://bun.com/llms.txt # Bun ## Docs - [Welcome to Bun](https://bun.com/docs/index.md): Bun is an all-in-one…”
- [probe] “PROBE docs-md: HTTP 200 at https://bun.com/docs.md # Welcome to Bun > Bun is an all-in-one toolkit for developing modern JavaScript/TypeScr…”
- [probe] “PROBE openapi: all candidate paths 404 (https://bun.com/openapi.json, https://bun.com/swagger.json, https://bun.com/api/openapi.json, https:…”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnuvnone0/10uv is a CLI package manager; the evidence pack shows no versioned API surface, API reference, or documented deprecation policy for such an API — only CLI commands, self-update, and docs indexing are mentioned. The axis is applicable (a tool could publish versioned APIs/CLI compatibility guarantees with deprecation notices) but no such policy is evidenced.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.astral.sh/openapi.json, https://docs.astral.sh/swagger.json, https://docs.astral.sh/api…”
- [claimed-docs] “uv publishes an llms.txt index of its documentation at docs.astral.sh/uv/llms.txt (served as text/plain): "# uv > uv is an extremely fast Py…”
- [probe] “official CLI documented at https://docs.astral.sh/uv/reference/cli/”
Bun (package manager)none0/10No evidence of a versioned API surface or documented deprecation policy for Bun's package manager; docs cover install/lockfile/workspaces features but nothing about API versioning guarantees or deprecation timelines, and no OpenAPI/spec was found (bun-probe-3 shows 404s).
- [probe] “PROBE openapi: all candidate paths 404 (https://bun.com/openapi.json, https://bun.com/swagger.json, https://bun.com/api/openapi.json, https:…”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round to Bun (package manager)uv supports some bulk-style operations — importing all dependencies from a requirements.txt via `uv add -r` (uv-docs-42), workspace support for managing multiple sub-projects (uv-docs-32/56), and lockfile-wide upgrade operations (uv-docs-9/39) — but there is no explicit 'bulk operate across many items' feature (e.g., batch scripting many independent tasks, mass tool upgrades, or fleet-style operations) documented or discussed by users. Missing for 10: dedicated bulk/batch command documentation, evidence of scaling to many independent items (not just one project's dependency tree), and hands-on confirmation of bulk workflows.
- [claimed-docs] “If you're migrating from a `requirements.txt` file, you can use `uv add` with the `-r` flag to add all dependencies from the file”
- [claimed-docs] “Supports Cargo-style [workspaces](concepts/projects/workspaces/) for scalable projects.”
- [claimed-docs] “Supports Cargo-style workspaces for scalable projects.”
- [claimed-docs] “The `--upgrade-package` flag will attempt to update the specified package to the latest compatible version, while keeping the rest of the lo…”
- [claimed-docs] “To upgrade a package, run `uv lock` with the `--upgrade-package` flag”
Bun's CLI supports several genuine bulk operations useful for automation: filtering/installing across many workspaces with `--filter` or glob patterns (bun-docs-9, bun-docs-21, bun-docs-32), bulk vulnerability remediation via `bun audit --fix` upgrading every vulnerable package at once (bun-docs-7), and shared version catalogs applied across many packages (bun-docs-11, bun-docs-22). These are documented, scriptable CLI behaviors well-suited to programmatic/AI-driven automation, but there is no explicit AI-native batch API, no independent corroboration of large-scale bulk runs, and community threads raise open monorepo-script gaps (bun-comm-10). Missing for 10: a dedicated programmatic/bulk API beyond CLI flags, independent hands-on evidence of large-scale multi-package operations succeeding, and confirmation of per-package script execution at scale in monorepos.
- [claimed-docs] “Runs the audit, then upgrades each vulnerable package to the lowest non-vulnerable version that every dependent's range allows, and installs…”
- [claimed-docs] “Install dependencies for all workspaces starting with `pkg-` except for `pkg-c`”
- [claimed-docs] “When many packages need the same dependency versions, define those versions once in a catalog in the root `package.json`”
- [claimed-docs] “Install dependencies for only `pkg-a` in `./packages/pkg-a`”
- [claimed-docs] “When many packages need the same dependency versions, define those versions once in a catalog in the root `package.json` and reference them …”
- [claimed-docs] “In a monorepo, you can install the dependencies for a subset of packages using the `--filter` flag.”
- [community] “So can I use bun now in pnpm monorepo without problems? I like bun and want to try it out more but also, I don't want to do the hassle of mi…”
Cross platform — stories about cross platform in this arenaCross platform
Stories about cross platform in this arena
Platform parity
developerUse the same workflow and config on macOS, Linux, and Windows
weight 2 · round to uvuv's lockfile is explicitly documented as cross-platform, and it ships standalone installers (curl-based) plus pip installation, with consistent CLI commands (`uv add`, `uv run`, `uv tool install`, etc.) that work the same way regardless of OS. Community comments corroborate a consistent, fast workflow but don't specifically stress-test Windows parity. Missing for 10: explicit Windows-specific documentation/testing, independent hands-on confirmation of identical behavior across macOS/Linux/Windows, and any discussion of platform-specific quirks.
- [claimed-docs] “`uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [github] “Installable without Rust or Python via `curl` or `pip`.”
- [claimed-docs] “A single tool to replace `pip`, `pip-tools`, `pipx`, `poetry`, `pyenv`, `twine`, `virtualenv`, and more.”
- [community] “Tried uv a while ago and I was shocked by how fast and easy it is to use. There's basically no reason to use pip anymore, and if you're usin…”
- [community] “UV is fast, like FAST. Plus, it removes the need for pyenv and pip for me... no need to activate env or anything, uv run automatically runs …”
Bun's docs confirm platform-aware install behavior (e.g., hardlink-based node_modules specifically on Linux and Windows) and its package manager is documented to work as a drop-in for npm/yarn/pnpm across projects (bun-docs-25, bun-docs-26). However, community reports flag Windows-specific install bugs/crashes when switching between WSL and native Windows, suggesting the workflow isn't perfectly uniform across all three OSes (bun-comm-7), while other users confirm smooth cross-platform monorepo use (bun-comm-6). Missing for 10: explicit macOS-specific documentation, first-party statement of full config/workflow parity across all three OSes, and resolution of the reported Windows install bugs.
- [claimed-docs] “On Linux and Windows, Bun uses hardlinks to "copy" a module into a project's `node_modules` directory, so the contents of the package only e…”
- [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”
- [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”
- [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
Ecosystem extensibility — stories about ecosystem extensibility in this arenaEcosystem extensibility
Stories about ecosystem extensibility in this arena
Extensibility
developerExtend the manager through third-party taps, overlays, plugins, or backends
weight 1 · round drawnuvnone0/10The evidence pack contains no mention of any plugin system, third-party backend hooks, taps, or overlay mechanism for uv; all citations describe uv's built-in commands (add/remove/run/tool/venv/cache) rather than any extensibility API for third parties to hook into the manager. This is a fair axis for a package/project manager (comparable to pip plugins or poetry plugins), but no evidence shows uv supports it.
Private registries
platform-engineerPoint the manager at private registries or mirrors with scoped authentication
weight 2 · round drawnuvnone0/10The evidence pack covers uv's project management, tools, caching, and pip-compatibility features but contains no mention of configuring private package indexes, mirrors, or scoped authentication credentials. This is a fair axis for a package manager, but no supporting evidence exists in the pack.
Bun (package manager)none0/10The evidence pack covers install speed, lockfiles, workspaces, caching, audit, and pm subcommands, but contains no mention of configuring private registries, mirrors, scoped registries, or authentication tokens (e.g., via bunfig.toml or .npmrc equivalents). This is a fair capability for a package manager to be judged on, but nothing in the pack demonstrates it.
Registry
developerInstall almost anything I need from a large, actively maintained package registry or repository
weight 2 · round drawnuv fully supports installing Python packages and tools via uv add, uv pip, uv tool install/uvx, all of which draw on the standard Python package ecosystem (PyPI) and are corroborated by extensive community use for real-world packages like torch, ruff, and pycowsay, showing it can fetch a huge range of actively maintained packages quickly and reliably. missing for 10: explicit mention of PyPI/registry scale or freshness, and independent benchmarking of registry breadth vs pip/conda.
- [claimed-docs] “You can add dependencies to your `pyproject.toml` with the `uv add` command. This will also update the lockfile and project environment”
- [claimed-docs] “The `uv pip` interface exposes the speed and functionality of uv to power users and projects that are not ready to transition away from `pip…”
- [claimed-docs] “uv provides a drop-in replacement for common `pip`, `pip-tools`, and `virtualenv` commands.”
- [claimed-docs] “Install a tool with `uv tool install`: $ uv tool install ruff”
- [claimed-docs] “$ uvx pycowsay 'hello world!'”
- [community] “Tried uv a while ago and I was shocked by how fast and easy it is to use. There's basically no reason to use pip anymore, and if you're usin…”
- [community] “UV is fast, like FAST. Plus, it removes the need for pyenv and pip for me... no need to activate env or anything, uv run automatically runs …”
- [community] “the 86GB python dependency download cache on my primary SSD, most of which can be attributed to the 50 different versions of torch... even u…”
Bun is explicitly designed as an npm-compatible package manager, installing directly from the npm registry (the largest JS package ecosystem) with lockfile migration from npm/yarn/pnpm, global installs, bunx for one-off execution, and workspace/monorepo support, all documented extensively. Community reports corroborate real-world usage of `bun install` against npm packages, with some install reliability bugs and edge-case runtime incompatibilities (unrelated to registry breadth) noted as caveats. Missing for 10: independent benchmark of registry breadth/failure-rate across large package sets, and resolution of noted install crash bugs.
- [claimed-docs] “⚡️ 25x faster — Switch from `npm install` to `bun install` in any Node.js project to make your installations up to 25x faster.”
- [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles: `yarn.lock` (v1), `package-lock…”
- [claimed-docs] “It's a standalone tool that works in existing Node.js projects; if your project has a `package.json`, you can use `bun install`.”
- [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”
- [claimed-docs] “bunx cowsay 'Hello, world!' # execute a package”
- [claimed-docs] “npm-compatible, up to 30× faster. Workspaces, catalogs, overrides, patches and a lockfile you can read.”
- [community] “You can use Bun as package manager only. You don't have to use Bun as runtime.”
- [community] “I used bun for the first time last week. It was awesome! The built-in server and SQLite meant i didn't need any dependencies besides bun its…”
- [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
Install reproducibility — stories about install reproducibility in this arenaInstall reproducibility
Stories about install reproducibility in this arena
Bootstrap
developerBootstrap a fresh clone with one command that installs everything the project declares
weight 2 · round drawnuv's project workflow (uv init, uv add, uv.lock cross-platform lockfile) combined with `uv run` automatically creating/syncing the environment before executing anything means a fresh clone can be bootstrapped and run with a single command, as confirmed by docs (uv-docs-17, uv-docs-16) and hands-on community reports ('no need to activate env or anything, uv run automatically runs your code through the env' — uv-comm-6; 'The venv and your Python install are just handled for you by uv run' — uv-comm-10). missing for 10: no explicit citation of the dedicated `uv sync` subcommand or an end-to-end fresh-clone walkthrough in the evidence pack.
- [claimed-docs] “`uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “$ uv run ruff check All checks passed!”
- [claimed-docs] “$ uv init example Initialized project `example` at `/home/user/example`”
- [community] “UV is fast, like FAST. Plus, it removes the need for pyenv and pip for me... no need to activate env or anything, uv run automatically runs …”
- [community] “The biggest praise I can give uv is that as a non Python dev, it makes Python a lot more accessible... With uv, you don't have to care about…”
Bun's `bun install` reads package.json/workspaces and lockfile, migrates other lockfiles automatically, and supports `--frozen-lockfile` for reproducible installs, directly matching the one-command bootstrap story; community posts also confirm real-world use as a package manager. Missing for 10: independent benchmarking of fresh-clone bootstrap reliability across OSes, and some community reports of install crashes/edge-case bugs (old lockfiles, WSL/Windows switching) that add minor caveats.
- [claimed-docs] “It's a standalone tool that works in existing Node.js projects; if your project has a `package.json`, you can use `bun install`.”
- [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
- [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles: `yarn.lock` (v1), `package-lock…”
- [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
- [claimed-docs] “With workspaces, you develop several independent packages in a single repository, a _monorepo_.”
- [community] “You can use Bun as package manager only. You don't have to use Bun as runtime.”
- [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”
- [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
Lockfiles
platform-engineerEnforce a frozen/immutable lockfile mode that fails the install when the manifest and lockfile disagree
weight 2 · round to Bun (package manager)uvnone0/10The evidence pack confirms uv has a lockfile (uv.lock) and commands like uv add/uv lock --upgrade-package, but nowhere does it mention a --frozen or --locked flag (or any mode) that fails an install when the manifest and lockfile diverge. Since lockfile reproducibility is clearly an applicable axis for a package manager but no supporting evidence exists, this is 'none' rather than 'na'.
- [claimed-docs] “`uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “The `--upgrade-package` flag will attempt to update the specified package to the latest compatible version, while keeping the rest of the lo…”
- [claimed-docs] “To upgrade a package, run `uv lock` with the `--upgrade-package` flag”
Bun's docs explicitly document `--frozen-lockfile` for reproducible installs, stating Bun installs the exact versions in the lockfile and does not update it, which matches the enforcement behavior platform engineers need; the lockfile format and reproducibility model are also well documented. missing for 10: explicit confirmation/example of the install failing (non-zero exit) when manifest and lockfile disagree, and independent/community corroboration of this specific flag's failure behavior.
- [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
- [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
- [claimed-docs] “Bun v1.2 changed the default lockfile format to the text-based `bun.lock`.”
developerInstall dependencies from a lockfile and get the exact same resolved versions on every machine
weight 3 · round to Bun (package manager)uv's `uv.lock` is described as a cross-platform lockfile with exact dependency information, and `uv add`/`uv lock --upgrade-package` explicitly preserve the rest of the lockfile intact, supporting deterministic, reproducible installs across machines. Missing for 10: explicit documentation of the `uv sync` command for installing strictly from the lockfile, and independent/hands-on confirmation that resolved versions are identical across different OS/machines.
- [claimed-docs] “`uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “You can add dependencies to your `pyproject.toml` with the `uv add` command. This will also update the lockfile and project environment”
- [claimed-docs] “The `--upgrade-package` flag will attempt to update the specified package to the latest compatible version, while keeping the rest of the lo…”
- [claimed-docs] “To upgrade a package, run `uv lock` with the `--upgrade-package` flag”
Bun documents a lockfile (bun.lock) that captures resolved versions and an explicit --frozen-lockfile flag that installs exact versions without updating, directly matching the reproducibility story; it also auto-migrates from npm/yarn/pnpm lockfiles. A community report notes occasional install crashes tied to stale lockfiles/node_modules, a minor real-world caveat rather than a fundamental contradiction. Missing for 10: independent large-scale reproducibility testing/benchmarks and resolution of the noted crash bug reports.
- [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
- [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
- [claimed-docs] “Bun v1.2 changed the default lockfile format to the text-based `bun.lock`.”
- [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles”
- [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
Pinning
developerPin exact versions of packages and tools per project and have the manager respect those pins
weight 3 · round drawnuv.lock provides exact cross-platform dependency pinning respected by uv sync/run, uv python pin pins Python version per project, and tool installs respect specified version constraints on upgrade; community feedback corroborates reliable reproducible behavior. Missing for 10: no independent hands-on test explicitly verifying pin enforcement across CI/multiple machines beyond docs claims.
- [claimed-docs] “`uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “You can add dependencies to your `pyproject.toml` with the `uv add` command. This will also update the lockfile and project environment”
- [claimed-docs] “To remove a package, you can use `uv remove`”
- [github] “Use a specific Python version in the current directory: console $ uv python pin 3.11 Pinned `.python-version` to `3.11`”
- [claimed-docs] “This will respect the Python version pinned in the project.”
- [claimed-docs] “Tool upgrades will respect the version constraints provided when installing the tool.”
- [community] “Tried uv a while ago and I was shocked by how fast and easy it is to use. There's basically no reason to use pip anymore, and if you're usin…”
- [community] “uv is much faster than both [pyenv and poetry], has a more ergonomic CLI, and solves both of the issues I just mentioned [poetry resolver st…”
Bun generates a lockfile (bun.lock) that pins exact resolved versions, and `bun install --frozen-lockfile` explicitly installs those exact versions without updating, satisfying per-project version pinning; overrides/resolutions further let developers force exact versions across the tree. missing for 10: independent/hands-on confirmation specifically testing that frozen-lockfile pins are honored under edge cases (only general community praise/issues about monorepo installs, not pin-specific verification).
- [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
- [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
- [claimed-docs] “Bun v1.2 changed the default lockfile format to the text-based `bun.lock`.”
- [claimed-docs] “Bun supports npm's `"overrides"` and Yarn's `"resolutions"` in `package.json`. Both specify a version range for _metadependencies_”
- [claimed-docs] “Bun supports npm's `"overrides"` and Yarn's `"resolutions"` in `package.json`.”
- [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”
Migration adoption — stories about migration adoption in this arenaMigration adoption
Stories about migration adoption in this arena
Compatibility
switcherKeep using familiar commands and interface conventions from the incumbent tool while adopting this manager
weight 2 · round to Bun (package manager)uv explicitly ships a `uv pip` interface described as a drop-in replacement for common pip/pip-tools/virtualenv commands, letting switchers keep familiar syntax while adopting uv (uv-docs-5, uv-docs-31), and also supports migrating requirements.txt via `uv add -r` (uv-docs-42). However, hands-on community reports show real friction: missing `uv pip install --user` support, `uv pip` not being a full pip replacement in some workflows, and non-standard handling of things like NVIDIA's package hacks or pre-releases (uv-comm-8, uv-comm-12, uv-comm-16). Missing for 10: independent verification that all common pip/poetry/pyenv command idioms map cleanly, and resolution of documented edge-case incompatibilities.
- [claimed-docs] “The `uv pip` interface exposes the speed and functionality of uv to power users and projects that are not ready to transition away from `pip…”
- [claimed-docs] “uv provides a drop-in replacement for common `pip`, `pip-tools`, and `virtualenv` commands.”
- [claimed-docs] “If you're migrating from a `requirements.txt` file, you can use `uv add` with the `-r` flag to add all dependencies from the file”
- [community] “Lack of `uv pip install --user` has made transitioning our existing python environment a bit more challenging than I'd like, but not a deal …”
- [community] “This does not work with uv, even with the `uv pip` interface, because uv rightly doesn't put up with that shit [NVIDIA's registry-breaking p…”
- [community] “1. It tries to do too many things... 2. You end up needing to use `uv pip` so it's not even a full replacement for pip. 3. It does not play …”
Bun explicitly positions itself as a drop-in replacement for npm/yarn/pnpm, supporting familiar commands (`bun install`, `bunx`), automatic migration of existing `yarn.lock`/`package-lock.json`/`pnpm-lock.yaml` files, and npm-compatible fields like `overrides`/`resolutions`, letting switchers keep muscle-memory commands and config conventions (bun-docs-1, bun-docs-2, bun-docs-17, bun-docs-18, bun-docs-26, bun-docs-31). Community members confirm they use Bun purely as a package manager without switching runtimes, easing adoption (bun-comm-2, bun-comm-4). Missing for 10: independent confirmation of complete command-surface parity for less common workflows, and some community reports of monorepo/lockfile migration friction and crashes that qualify a fully seamless switch (bun-comm-7, bun-comm-10).
- [claimed-docs] “⚡️ 25x faster — Switch from `npm install` to `bun install` in any Node.js project to make your installations up to 25x faster.”
- [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles: `yarn.lock` (v1), `package-lock…”
- [claimed-docs] “It's a standalone tool that works in existing Node.js projects; if your project has a `package.json`, you can use `bun install`.”
- [claimed-docs] “Bun supports npm's `"overrides"` and Yarn's `"resolutions"` in `package.json`. Both specify a version range for _metadependencies_”
- [claimed-docs] “The `bun` CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for `npm`, `yarn`, and `pnpm`.”
- [claimed-docs] “npm-compatible, up to 30× faster. Workspaces, catalogs, overrides, patches and a lockfile you can read.”
- [community] “You can use Bun as package manager only. You don't have to use Bun as runtime.”
- [community] “Didn't prevent me from switching to Bun as the cost is 0.”
- [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
- [community] “So can I use bun now in pnpm monorepo without problems? I like bun and want to try it out more but also, I don't want to do the hassle of mi…”
Migration
switcherMigrate an existing project from the incumbent tool with documented import or conversion tooling
weight 2 · round to Bun (package manager)uv documents a concrete import path from pip's requirements.txt (`uv add -r`) and offers a `uv pip` drop-in interface plus positions itself as a pip/pip-tools/poetry/pyenv/virtualenv replacement, and community reports confirm many users migrating with minor friction (e.g. missing `--user` flag). However there is no dedicated conversion tool or documented guide for importing an existing poetry.lock/Pipfile/conda environment, and some community feedback shows migration is only partial (still using `uv pip`, or treating uv as 'just a faster pip+venv'). missing for 10: dedicated poetry/Pipfile/conda lockfile conversion tooling, an official step-by-step migration guide beyond the requirements.txt case, independent hands-on confirmation of full incumbent-tool migration.
- [claimed-docs] “If you're migrating from a `requirements.txt` file, you can use `uv add` with the `-r` flag to add all dependencies from the file”
- [claimed-docs] “A single tool to replace `pip`, `pip-tools`, `pipx`, `poetry`, `pyenv`, `twine`, `virtualenv`, and more.”
- [claimed-docs] “The `uv pip` interface exposes the speed and functionality of uv to power users and projects that are not ready to transition away from `pip…”
- [claimed-docs] “uv provides a drop-in replacement for common `pip`, `pip-tools`, and `virtualenv` commands.”
- [community] “Lack of `uv pip install --user` has made transitioning our existing python environment a bit more challenging than I'd like, but not a deal …”
- [community] “UV is great but I use it as a more convenient pip+venv. Maybe I'm not using it to it's full potential.”
- [community] “1. It tries to do too many things... 2. You end up needing to use `uv pip` so it's not even a full replacement for pip. 3. It does not play …”
Bun documents drop-in npm compatibility ("bun install in any Node.js project") and automatic migration of existing yarn.lock, package-lock.json, and pnpm-lock.yaml files into bun.lock, directly addressing incumbent-tool migration. Community reports confirm it's usable as a pure package-manager swap, though some note lockfile/node_modules switching bugs and monorepo migration uncertainty. Missing for 10: independent case studies of full large-project migrations, and resolution of reported install crashes when switching lockfile formats.
- [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles: `yarn.lock` (v1), `package-lock…”
- [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles”
- [claimed-docs] “When you run `bun install` in a project without a `bun.lock`, Bun automatically migrates existing lockfiles:”
- [claimed-docs] “It's a standalone tool that works in existing Node.js projects; if your project has a `package.json`, you can use `bun install`.”
- [claimed-docs] “⚡️ 25x faster — Switch from `npm install` to `bun install` in any Node.js project to make your installations up to 25x faster.”
- [community] “You can use Bun as package manager only. You don't have to use Bun as runtime.”
- [community] “FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modul…”
- [community] “So can I use bun now in pnpm monorepo without problems? I like bun and want to try it out more but also, I don't want to do the hassle of mi…”
Monorepo workspaces — stories about monorepo workspaces in this arenaMonorepo workspaces
Stories about monorepo workspaces in this arena
Workspaces
developerManage many packages in one monorepo with workspaces sharing a single lockfile and cross-linked local dependencies
weight 3 · round to Bun (package manager)uv explicitly documents Cargo-style workspaces for scalable monorepo projects and a single cross-platform uv.lock lockfile shared across the project, which is the core mechanism for cross-linked local dependencies. Missing for 10: independent/hands-on community confirmation specifically of workspace usage (all community comments concern general uv speed/behavior, not workspaces), and no detail on workspace-specific edge cases or member-linking syntax beyond the doc pointer.
- [claimed-docs] “Supports Cargo-style [workspaces](concepts/projects/workspaces/) for scalable projects.”
- [claimed-docs] “Supports Cargo-style workspaces for scalable projects.”
- [claimed-docs] “`uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock is a cross-platform lockfile that contains exact information about your project's dependencies.”
Bun's docs thoroughly describe monorepo workspaces with a single shared lockfile (bun.lock), cross-linked local packages, catalogs for shared versions, --filter for scoping installs, and hoisting-barrier controls for self-contained workspaces. Community evidence corroborates reliability gains for monorepo installs (isolated installs), though some users report install bugs and open questions about per-package script execution. Missing for 10: independent large-scale case study of cross-linked local dependency workflows and resolution of the unanswered community question about running scripts on specific workspace packages.
- [claimed-docs] “With workspaces, you develop several independent packages in a single repository, a _monorepo_.”
- [claimed-docs] “Install dependencies for all workspaces starting with `pkg-` except for `pkg-c`”
- [claimed-docs] “Mark such a workspace as self-contained... For that workspace `bun install` then behaves as a hoisting barrier”
- [claimed-docs] “When many packages need the same dependency versions, define those versions once in a catalog in the root `package.json`”
- [claimed-docs] “Install dependencies for only `pkg-a` in `./packages/pkg-a`”
- [claimed-docs] “When many packages need the same dependency versions, define those versions once in a catalog in the root `package.json` and reference them …”
- [claimed-docs] “In a monorepo, you can install the dependencies for a subset of packages using the `--filter` flag.”
- [claimed-docs] “Mark such a workspace as self-contained... nothing it depends on... is placed above `apps/desktop/node_modules`, so that directory is a comp…”
- [claimed-docs] “Bun supports [`workspaces`](https://docs.npmjs.com/cli/v9/using-npm/workspaces?v=true#description) in `package.json`. With workspaces, you d…”
- [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
- [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”
- [community] “So can I use bun now in pnpm monorepo without problems? I like bun and want to try it out more but also, I don't want to do the hassle of mi…”
developerRun installs and scripts filtered to a subset of workspace packages (including only those affected by a change)
weight 2 · round to Bun (package manager)uvnone0/10Evidence confirms uv supports Cargo-style workspaces (uv-docs-32, uv-docs-56) but contains no mention of filtering installs or `uv run` scripts to a subset of workspace packages, package-selection flags (e.g. per-package targeting), or any 'affected packages' detection mechanism.
- [claimed-docs] “Supports Cargo-style [workspaces](concepts/projects/workspaces/) for scalable projects.”
- [claimed-docs] “Supports Cargo-style workspaces for scalable projects.”
Bun's docs explicitly support installing (and by extension running) commands scoped to a subset of workspace packages via the `--filter` flag, including glob patterns like `pkg-*` excluding `pkg-c`, or a single package path (bun-docs-32, bun-docs-9, bun-docs-21). However, there is no documented mechanism for detecting packages 'affected by a change' (e.g., git-diff-based filtering as in Turborepo/Nx), and a community comment expresses uncertainty about whether running scripts on specific packages in a monorepo works reliably (bun-comm-10). Missing for 10: change-affected/git-diff-based filtering, explicit script-running (not just install) filter examples, and independent hands-on confirmation.
- [claimed-docs] “In a monorepo, you can install the dependencies for a subset of packages using the `--filter` flag.”
- [claimed-docs] “Install dependencies for all workspaces starting with `pkg-` except for `pkg-c`”
- [claimed-docs] “Install dependencies for only `pkg-a` in `./packages/pkg-a`”
- [community] “So can I use bun now in pnpm monorepo without problems? I like bun and want to try it out more but also, I don't want to do the hassle of mi…”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userRead the product's source under an open license
weight 2 · round to uvThe evidence confirms uv's source code lives in a public GitHub repository (astral-sh/uv) that is directly quoted and referenced, indicating openly readable source, but no citation in the pack states or confirms an explicit open-source license (e.g., MIT/Apache) for the project. missing for 10: explicit license file/badge citation, independent confirmation of license terms, and any docs page stating the licensing model.
- [github] “Use a specific Python version in the current directory: console $ uv python pin 3.11 Pinned `.python-version` to `3.11`”
- [github] “Installable without Rust or Python via `curl` or `pip`.”
- [github] “uv can update itself to the latest version: bash uv self update ”
- [github] “$ uv python pin 3.11 Pinned `.python-version` to `3.11`”
- [github] “$ uv python pin 3.11 [] Pinned `.python-version` to `3.11`”
Bun (package manager)none0/10The evidence pack contains no reference to Bun's source code repository, license, or any statement about open-source availability — all citations are docs/CLI usage examples or community sentiment about performance, none addressing openness of the source. Missing for 10: any mention of a GitHub repo, license (e.g., MIT), or contribution/source-availability documentation.
Performance caching — stories about performance caching in this arenaPerformance caching
Stories about performance caching in this arena
Benchmarks
developerSee published benchmarks or measured numbers backing the manager's speed claims
weight 1 · round to Bun (package manager)uvnone0/10Evidence contains only qualitative claims of speed ('extremely fast', community anecdotes like 'confusingly fast') but no published benchmark suite, methodology, or measured numbers from Astral or third parties; one community comment (uv-comm-19) references informal internal benchmarking but reports no figures and notes gains can vanish under certain configs, undermining rather than substantiating a benchmark claim.
- [claimed-docs] “uv publishes an llms.txt index of its documentation at docs.astral.sh/uv/llms.txt (served as text/plain): "# uv > uv is an extremely fast Py…”
- [community] “When you're used to pip, it's just confusingly fast. More than once I thought maybe it didn't work because it returned too quickly.”
- [community] “Tried uv a while ago and I was shocked by how fast and easy it is to use. There's basically no reason to use pip anymore, and if you're usin…”
- [community] “At Plotly we did a decent amount of benchmarking... We found you lost almost all of the speed gains if you configured uv behave as much like…”
Bun's docs and marketing page publish concrete speed claims (25x/30x faster) and even a specific measured number comparison (bun v1.4 0.21s vs npm v12.0.2 4.45s), which goes beyond a bare marketing slogan. However, these are all first-party vendor numbers with no disclosed benchmark methodology (hardware, package set, versions) and no independent third-party benchmark reproduction in the evidence; community comments only vaguely corroborate perceived speedups (e.g., isolated installs 10-20x faster on Windows) without rigorous numbers. Missing for 10: independent/third-party benchmark verification, transparent methodology/environment details for the vendor numbers.
- [claimed-docs] “⚡️ 25x faster — Switch from `npm install` to `bun install` in any Node.js project to make your installations up to 25x faster.”
- [claimed-docs] “bun v1.4 0.21s ... npm v12.0.2 4.45s”
- [claimed-docs] “npm-compatible, up to 30× faster. Workspaces, catalogs, overrides, patches and a lockfile you can read.”
- [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”
Binary caching
developerInstall prebuilt binary packages from a cache instead of compiling from source
weight 3 · round to uvuv installs Python packages via wheels (prebuilt binaries) by default and uses a global cache to avoid re-downloading/re-building dependencies already fetched, with docs confirming aggressive caching and disk-efficient global cache for deduplication; community reports corroborate the speed gains from this caching. missing for 10: explicit first-party documentation contrasting wheel vs sdist source builds, and independent benchmarking specifically isolating binary-cache reuse rather than general speed.
- [claimed-docs] “uv uses aggressive caching to avoid re-downloading (and re-building) dependencies that have already been accessed in prior runs.”
- [claimed-docs] “Disk-space efficient, with a [global cache](concepts/cache/) for dependency deduplication.”
- [claimed-docs] “you can add cache key entries under `tool.uv.cache-keys`, which covers both file paths and Git commit hashes.”
- [community] “When you're used to pip, it's just confusingly fast. More than once I thought maybe it didn't work because it returned too quickly.”
- [community] “Tried uv a while ago and I was shocked by how fast and easy it is to use. There's basically no reason to use pip anymore, and if you're usin…”
- [community] “Switched to uv and everything just worked [after pip's cache was taking up too much space on a shared server with no root access].”
Bun's docs describe a global package cache (~/.bun/install/cache) with hardlinked installs, and explicitly state a required dependency not found in the cache errors rather than falling back to compiling/fetching from source, supporting fast reuse instead of source builds. Community and benchmark evidence corroborate large speedups from this caching behavior. missing for 10: explicit documentation of prebuilt *binary* (native addon) caching versus source compilation, and independent hands-on verification of that specific scenario.
- [claimed-docs] “Bun stores every package downloaded from the registry in a global cache at `~/.bun/install/cache`”
- [claimed-docs] “a required dependency that is not cached is an error”
- [claimed-docs] “On Linux and Windows, Bun uses hardlinks to "copy" a module into a project's `node_modules` directory, so the contents of the package only e…”
- [claimed-docs] “bun v1.4 0.21s ... npm v12.0.2 4.45s”
- [community] “Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral …”
Ci speed
platform-engineerMake CI installs fast with a documented cache-restore setup and offline-capable installs
weight 3 · round drawnuv documents a clear CI caching workflow via the official `astral-sh/setup-uv` GitHub Action (installs uv, persists cache) plus a global dependency cache, cache-key config, and cache-clean commands, which directly supports fast CI installs with cache-restore. However, there is no explicit documentation of an 'offline mode' or offline-install flag, and community reports note real caching gaps (e.g. uvx sometimes re-downloading dependencies, large disk cache growth) that undercut a fully offline-capable guarantee. Missing for 10: explicit offline-install/--offline flag documentation, first-party guidance on air-gapped CI use, and confirmation that cache-restore avoids network calls entirely.
- [claimed-docs] “we recommend the official `astral-sh/setup-uv` action, which installs uv, adds it to PATH, (optionally) persists the cache, and more”
- [claimed-docs] “we recommend the official [`astral-sh/setup-uv`](https://github.com/astral-sh/setup-uv) action, which installs uv, adds it to PATH, (optiona…”
- [claimed-docs] “Disk-space efficient, with a [global cache](concepts/cache/) for dependency deduplication.”
- [claimed-docs] “uv uses aggressive caching to avoid re-downloading (and re-building) dependencies that have already been accessed in prior runs.”
- [claimed-docs] “To clear the cache entirely, run `uv cache clean`. To clear the cache for a specific package, run `uv cache clean <package-name>`.”
- [claimed-docs] “you can add cache key entries under `tool.uv.cache-keys`, which covers both file paths and Git commit hashes.”
- [claimed-docs] “you can add cache key entries under `tool.uv.cache-keys`, which covers both file paths and Git commit hashes”
- [community] “I continue to be puzzled why sometime running uvx (uv tool run) will redownload all dependencies even though it just downloaded them for ano…”
- [community] “the 86GB python dependency download cache on my primary SSD, most of which can be attributed to the 50 different versions of torch... even u…”
Bun documents a global package cache (~/.bun/install/cache), a strict offline mode where missing cached packages error instead of hitting the network, and --frozen-lockfile for reproducible installs — the core primitives for fast, cache-restorable, offline-capable CI installs. However there's no explicit CI-specific guide (e.g. GitHub Actions cache-restore recipe) tying these primitives together for a platform engineer. Missing for 10: a documented CI/CD cache-restore workflow example, independent benchmarks of cache-restore behavior in CI.
- [claimed-docs] “Bun stores every package downloaded from the registry in a global cache at `~/.bun/install/cache`”
- [claimed-docs] “On Linux and Windows, Bun uses hardlinks to "copy" a module into a project's `node_modules` directory, so the contents of the package only e…”
- [claimed-docs] “Never touch the network (registry, tarball URLs, git); a required dependency that is not cached is an error”
- [claimed-docs] “a required dependency that is not cached is an error”
- [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
Disk efficiency
developerRely on a shared content-addressable store so the same dependency version is stored once on disk across all projects
weight 2 · round to Bun (package manager)uv's docs explicitly describe a global cache that deduplicates dependencies across projects ('Disk-space efficient, with a global cache for dependency deduplication') and detail cache management (cache-keys, cache clean) plus aggressive caching to avoid re-downloading previously accessed packages, directly matching the shared content-addressable store story. Community reports corroborate large speed/disk benefits, though one user notes uvx sometimes re-downloads dependencies unexpectedly, suggesting the caching isn't always perfectly hit. Missing for 10: explicit technical detail on content-addressing/hard-linking mechanism and independent verification of true single-copy-on-disk behavior across projects.
- [claimed-docs] “uv uses aggressive caching to avoid re-downloading (and re-building) dependencies that have already been accessed in prior runs.”
- [claimed-docs] “Disk-space efficient, with a [global cache](concepts/cache/) for dependency deduplication.”
- [claimed-docs] “To clear the cache entirely, run `uv cache clean`. To clear the cache for a specific package, run `uv cache clean <package-name>`.”
- [claimed-docs] “you can add cache key entries under `tool.uv.cache-keys`, which covers both file paths and Git commit hashes.”
- [claimed-docs] “you can add cache key entries under `tool.uv.cache-keys`, which covers both file paths and Git commit hashes”
- [community] “I continue to be puzzled why sometime running uvx (uv tool run) will redownload all dependencies even though it just downloaded them for ano…”
- [community] “Switched to uv and everything just worked [after pip's cache was taking up too much space on a shared server with no root access].”
Bun documents a global content-addressable cache at ~/.bun/install/cache storing every downloaded package once, and on Linux/Windows uses hardlinks so a package's contents exist in a single location on disk while being linked into each project's node_modules, directly matching the story. Missing for 10: independent hands-on benchmark/verification specifically confirming cross-project single-copy storage (community evidence discusses install speed/reliability but not disk dedup directly).
- [claimed-docs] “Bun stores every package downloaded from the registry in a global cache at `~/.bun/install/cache`”
- [claimed-docs] “On Linux and Windows, Bun uses hardlinks to "copy" a module into a project's `node_modules` directory, so the contents of the package only e…”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userOpt out of telemetry and usage tracking
weight 2 · round drawnuvnone0/10No evidence in the pack mentions telemetry, usage tracking, or an opt-out mechanism for uv; none of the docs or community items address this axis.
Security supply chain — stories about security supply chain in this arenaSecurity supply chain
Stories about security supply chain in this arena
Auditing
platform-engineerAudit installed dependencies for known vulnerabilities directly from the CLI
weight 3 · round to Bun (package manager)uvnone0/10No evidence pack item mentions vulnerability scanning, CVE auditing, or security advisories in uv's CLI; coverage is entirely about dependency management, tooling, caching, and Python version handling.
Bun ships a dedicated `bun audit` CLI command that reads the lockfile, checks packages against the npm advisory endpoint, and prints a vulnerability report, with `bun audit --fix` to auto-remediate — directly matching the platform-engineer's need to audit dependencies from the CLI. missing for 10: no independent/hands-on community corroboration of `bun audit` in practice, and no detail on report format or CI integration examples.
- [claimed-docs] “Bun reads the package list from `bun.lock` (no `node_modules` required), sends it to the npm advisory endpoint, and prints a report.”
- [claimed-docs] “Runs the audit, then upgrades each vulnerable package to the lowest non-vulnerable version that every dependent's range allows, and installs…”
Hardening
platform-engineerTurn on protections against malicious packages, such as blocking lifecycle scripts or enforcing a minimum release age
weight 2 · round to Bun (package manager)uvnone0/10No evidence in the pack mentions any supply-chain security controls like blocking lifecycle scripts, enforcing minimum package release age, or similar malicious-package protections; all citations concern project/tool management, caching, and general performance/UX feedback.
Bun ships strong default protection against malicious lifecycle scripts: it does not execute postinstall/lifecycle scripts by default, and platform-engineers can allowlist trusted packages via `trustedDependencies` (bun-docs-19, bun-docs-4). There is also a supply-chain audit command that checks the npm advisory database (bun-docs-6, bun-docs-7). However, no evidence exists of a 'minimum release age' enforcement feature, which is explicitly part of the user story. Missing for 10: minimum-release-age enforcement/config, independent/hands-on confirmation of the lifecycle-script blocking behavior in practice.
- [claimed-docs] “Bun does not execute arbitrary lifecycle scripts like `postinstall` for installed dependencies. Executing arbitrary scripts represents a pot…”
- [claimed-docs] “To tell Bun to allow lifecycle scripts for a particular package, add the package to `trustedDependencies` in your package.json.”
- [claimed-docs] “Bun reads the package list from `bun.lock` (no `node_modules` required), sends it to the npm advisory endpoint, and prints a report.”
- [claimed-docs] “Runs the audit, then upgrades each vulnerable package to the lowest non-vulnerable version that every dependent's range allows, and installs…”
Integrity
platform-engineerTrust that fetched packages are verified against checksums, signatures, or attestations before they run
weight 2 · round drawnuvnone0/10No evidence in the pack mentions checksum verification, package signing, or attestation checks before installing/running packages; docs cover caching, tool install, and lockfiles but not supply-chain verification mechanisms.
Bun (package manager)none0/10Bun's docs describe lockfiles, trustedDependencies, blocking of arbitrary postinstall scripts, and an npm-advisory-based audit command, but none of the evidence mentions checksum verification, package signature verification, or provenance/attestation checks before installing or running packages. missing for 10: explicit checksum/integrity hash verification, package signature verification, and supply-chain attestation (e.g. SLSA/sigstore) support.
- [claimed-docs] “To tell Bun to allow lifecycle scripts for a particular package, add the package to `trustedDependencies` in your package.json.”
- [claimed-docs] “Bun reads the package list from `bun.lock` (no `node_modules` required), sends it to the npm advisory endpoint, and prints a report.”
- [claimed-docs] “Bun does not execute arbitrary lifecycle scripts like `postinstall` for installed dependencies. Executing arbitrary scripts represents a pot…”
- [claimed-docs] “For reproducible installs, use `--frozen-lockfile`. Bun installs the exact versions specified in the lockfile and does not update it.”
- [claimed-docs] “`bun install` creates a lockfile called `bun.lock`.”
Toolchain management — stories about toolchain management in this arenaToolchain management
Stories about toolchain management in this arena
Runtimes
developerInstall and switch language runtimes or tool versions per project from a checked-in config file
weight 2 · round to uvuv supports `uv python pin 3.11` which writes a checked-in `.python-version` file, and `uv python install` to install runtimes, plus `uv tool install`/`uvx` for per-project tool versions pinned via pyproject.toml/lockfile. This directly matches installing/switching runtimes or tool versions from a checked-in config file. Missing for 10: independent hands-on confirmation specifically of `.python-version` switching behavior across projects (only vendor docs/GitHub README cited) and no community corroboration of multi-project runtime switching workflow.
- [github] “Use a specific Python version in the current directory: console $ uv python pin 3.11 Pinned `.python-version` to `3.11`”
- [github] “$ uv python pin 3.11 Pinned `.python-version` to `3.11`”
- [github] “$ uv python pin 3.11 [] Pinned `.python-version` to `3.11`”
- [claimed-docs] “Python can be installed with the `python install` command”
- [claimed-docs] “uv installs Python and allows quickly switching between versions.”
- [claimed-docs] “This will respect the Python version pinned in the project.”
- [claimed-docs] “$ uv tool install ruff Resolved 1 package in 6ms Installed 1 package in 2ms”
- [claimed-docs] “Install a tool with `uv tool install`”
Bun (package manager)none0/10The evidence pack covers Bun's package management features (lockfiles, workspaces, caching, audits) but contains no mention of a mechanism to pin or switch Bun/Node runtime versions per project via a checked-in config file (e.g., a .bun-version or engines-based version switcher). This capability is plausible for a JS toolchain tool, but nothing in the docs or community evidence demonstrates it.
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableuvn/auv is a Python package/project manager, not an AI agent or assistant; there is no evidence of MCP server integration in its feature set, and this axis is outside its product category.
Bun (package manager)n/aBun is a JavaScript runtime/package manager, not an AI agent or assistant that consumes external tools via MCP; the evidence is entirely about package installation, workspaces, lockfiles, and CLI features with no mention of MCP integration. Plugging MCP servers into a tool for agentic use is a category mismatch for a package manager.
ai-native userConnect an agent via an official MCP server
weight 3 · not comparableuvn/auv is a Python packaging/project tool, not an agent, and there is no evidence of an official MCP server for it; connecting agents via MCP is outside this product's category.
Bun (package manager)n/aBun is a package manager/runtime, not an agent; the story asks about connecting an agent via an official MCP server, which is a different product role. No evidence shows Bun exposing an MCP server endpoint, so the axis is a category mismatch rather than an unmet capability.
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · not comparableuvn/auv is a Python packaging/project tool; it has no concept of API credentials or agent identity/authorization scoping, so scoped/least-privilege credential issuance is a category error for this product type.
ai-native userBuild against official SDKs
weight 2 · not comparableuvnone0/10uv's evidence pack covers CLI commands, docs, and package management features, but there is no mention of an official SDK or programmatic API library that developers could build against for AI-native integration; the closest is the llms.txt documentation index, which is not an SDK.
Bun (package manager)n/aBun is a JavaScript runtime/package manager, not a platform or service that would expose 'official SDKs' for third-party developers to build against; the evidence pack covers package-management features (install, lockfiles, workspaces, audit) with no mention of publishing client SDKs. This story is a category mismatch for a package manager, so the axis does not apply.
ai-native userSubscribe to events via webhooks
weight 2 · not comparableuvn/auv is a Python packaging/project management CLI tool, not an event-driven service; webhooks/event subscriptions are not a relevant capability category for this kind of product.
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableuvn/auv is a Python packaging/project management tool with no data-analysis or insight-generation features; AI-generated insights from user data is a category error for this product type.
ai-native userSet up automations that run autonomously in the background
weight 2 · not comparableuvn/auv is a Python packaging/project management tool, not an automation/orchestration platform; there is no axis in the evidence for scheduling or running autonomous background automations, and this capability is outside its category (wrong axis, not a missing feature of this tool type).
Bun (package manager)n/aBun is a package manager/runtime toolkit; setting up autonomous background automations (e.g., agent scheduling/workflow orchestration) is not a fair axis for this product category — evidence pack is entirely about install/workspace/lockfile package-management features with no automation/agent orchestration capability shown.
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableuvn/auv is a Python package/project manager CLI, not an AI assistant product; the evidence pack shows no built-in AI assistant feature, and this axis is a category error for this type of tool.
ai-native userOperate the product with natural-language commands
weight 2 · not comparableuvnone0/10uv's entire interface is a structured CLI with explicit subcommands (uv init, uv add, uv run, uvx, etc.) documented across the evidence pack; there is no mention of natural-language parsing, an AI assistant, or NL-to-command translation anywhere in the docs or community discussion.
ai-native userTest against a sandbox environment without touching production data
weight 1 · not comparableuvn/auv is a Python package/project manager, not a service with production data or a sandbox/test-environment concept; testing against a sandbox vs production data is a category error for this kind of tool.
ai-native userDefine rules that trigger actions automatically on events
weight 3 · not comparableuvn/auv is a Python packaging/project management tool; it has no event-based rule/trigger/automation-workflow engine, and event-driven automation is outside its category (a buyer would use CI/CD or task schedulers for that, not uv itself). This is a wrong-axis question for a package manager, not a missing feature.
Bun (package manager)n/aBun is a package manager/runtime; no evidence describes any event-triggered rules engine or automation-trigger system, and this capability is outside the category of what a package manager does (a package manager could have lifecycle scripts, but no rule/trigger automation system is claimed).
ai-native userSchedule recurring jobs or workflows
weight 2 · not comparableuvn/auv is a Python packaging/project manager; scheduling recurring jobs or workflows is outside its product category — no scheduler/cron/orchestration feature is claimed or implied by any evidence.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableuvn/auv is a Python packaging/project manager (dependency installs, virtual envs, tool execution, lockfiles), not an automation/workflow platform; the story's concept of versioning, reviewing, and rolling back 'automations' (e.g., agent workflows) does not map to any uv capability in the evidence pack.
Bun (package manager)n/aBun is a JavaScript package manager/runtime; 'automations' in the AI-native sense (versioning, reviewing, and rolling back agent workflows/automations) is not something a package manager provides. Lockfiles version dependency trees, not automations, so this is a category mismatch rather than a missing feature.
ai-native userDo everything through the API that I can do in the UI
weight 2 · not comparableuvn/auv is a CLI/package-manager tool with no graphical or web UI and no separate API surface — the CLI itself is the sole interface, so a UI-vs-API parity question is a category error for this kind of product.
ai-native userExport all of my data in open formats and leave
weight 3 · not comparableuv stores all project state in plain, open formats (pyproject.toml, uv.lock) that live on the user's own filesystem rather than in a proprietary or hosted store, so there is inherently nothing to 'export' — the user already owns open, portable files. However, there's no explicit documentation framing this as a data-portability/export guarantee, and evidence doesn't address other local state (e.g., cache) or any hosted account data. Missing for 10: explicit vendor statement on data portability/no lock-in, documentation of exporting/migrating full project state, independent confirmation of no proprietary artifacts.
- [claimed-docs] “`uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock` is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv.lock is a cross-platform lockfile that contains exact information about your project's dependencies.”
- [claimed-docs] “uv uses aggressive caching to avoid re-downloading (and re-building) dependencies that have already been accessed in prior runs.”
- [claimed-docs] “To clear the cache entirely, run `uv cache clean`. To clear the cache for a specific package, run `uv cache clean <package-name>`.”
Bun (package manager)n/aBun is a local CLI package manager/runtime that operates on the user's own files (package.json, lockfile, node_modules) rather than storing user data in a vendor-controlled service; there is no 'your data' held by Bun to export and no lock-in to escape. This 'export and leave' story targets SaaS/data-hosting products, which is a different axis than a local dev tool.
ai-native userSelf-host the core product
weight 3 · not comparableuvn/auv is a local CLI package/project manager distributed as open-source binaries (installed via curl/pip) that runs entirely on the user's own machine; there is no hosted/SaaS version for which 'self-hosting' would be a meaningful alternative deployment choice. This axis is a category error for this kind of product.
ai-native userChoose where my data is stored (region/residency)
weight 2 · not comparableuvn/auv is a local Python package/project manager CLI tool with no hosted data storage or cloud service component, so data residency/region selection is a category error for this product type.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableuvn/auv is a Python package/project manager; it has no data-training or AI-model opt-out feature, and this axis is a category error for a package management CLI tool.
ai-native userControl data retention and deletion
weight 2 · not comparableuvn/auv is a local Python package/project manager CLI; it does not process, retain, or store user data on behalf of an AI workflow in a way that data-retention/deletion controls would apply. Its only local state is a build/dependency cache (clearable via `uv cache clean`), which is not about privacy-sensitive data retention — this axis is a category error for this product type.
developerHave the right tool versions and environment variables activate automatically when I enter a project directory
weight 1 · not comparableuv supports per-project Python version pinning (`uv python pin`, `.python-version`) and `uv run` automatically uses the correct interpreter/venv without manual activation, and community feedback confirms this removes the need to 'activate' environments manually. However, there is no evidence of automatic shell-hook style activation when simply `cd`-ing into a directory (no direnv-like trigger), nor of automatic environment-variable loading tied to directory entry — activation still requires invoking `uv run`/`uvx` explicitly. missing for 10: automatic directory-based activation without invoking a uv command, evidence of environment-variable (not just Python-version) auto-loading on cd, and independent confirmation of this exact workflow.
- [github] “Use a specific Python version in the current directory: console $ uv python pin 3.11 Pinned `.python-version` to `3.11`”
- [github] “$ uv python pin 3.11 Pinned `.python-version` to `3.11`”
- [community] “UV is fast, like FAST. Plus, it removes the need for pyenv and pip for me... no need to activate env or anything, uv run automatically runs …”
- [community] “The biggest praise I can give uv is that as a non Python dev, it makes Python a lot more accessible... With uv, you don't have to care about…”