Using uv and PEP 723 for Self-Contained Python Scripts

Original Article ↗ Hacker News Discussion ↗

What uv Is (and Isn’t)

  • Debate over the article saying this avoids “package managers” while centering uv, which is itself a fast Rust-based Python package/project manager.
  • Some argue the single-file + uv flow is much simpler than traditional Python tools; others emphasize it’s still a package manager and should be described as such.
  • There’s a side discussion about uv’s binary size vs system Python and what “small runtime” really means.

Workflows with Editors, LSPs, and Projects

  • Multiple people ask how to integrate PEP 723 + uv with LSP-based editors (Pyright, pylsp, VS Code, PyCharm).
  • Newer uv releases add uv python find --script foo.py, which users combine with Pyright or editor config to point to the correct environment.
  • Some use uv sync --script or --dry-run only to grab the venv path, acknowledging this as a hack.
  • A common workaround: develop as a normal project with pyproject.toml, then embed metadata into a standalone PEP 723 script at build time.

Ephemeral Virtualenvs, Caching, and Location

  • uv’s philosophy: venvs are ephemeral and fast to (re)create; for standalone scripts they live in a cache directory, for projects in .venv/ (configurable).
  • Users appreciate that venvs are reused unless dependencies or Python versions change; uv cache dir reveals where they live.
  • Hardlinking reduces disk cost even with many script-specific envs.

Self-Contained Scripts & Distribution (“Grandma Problem”)

  • Many praise putting dependencies inline for throwaway or utility scripts, replacing per-script venvs.
  • However, this still requires uv on the target machine; people note it doesn’t fully solve “send a script to nontechnical grandma.”
  • Suggested workarounds: curl-to-install-uv wrappers, bundling via PyInstaller, or older patterns where the script invokes pip itself.
  • Some think uv should ship with OSes; others push back on security implications of a default system tool that auto-downloads interpreters and packages.

Installing Python & System Integration

  • uv can install specific Python versions using standalone builds; environment variables can redirect installs and caches (e.g., to /tmp).
  • Some have replaced pyenv/poetry with uv entirely for both Python and tooling management.

Security, Trust, and Defaults

  • Concern: uv run file.py downloading dependencies (and even Python) by default is surprising and risky on a “system” tool.
  • Others reply that all package managers inherently download and run code; uv is not unique here, but bundling it by default would broaden the trust surface.
  • There is mention of MITM risk and the difference between trusting a distro vs blindly trusting a third-party binary source.

Alternatives and Prior Art

  • Hatch and PDM already support similar script-running features; the article is praised but noted as not unique.
  • Links to older single-file-with-dependencies approaches using just pip and venvs, and to tools like pip.wtf / pip-wtenv.
  • Some use marimo or juv for notebook-like workflows with uv-backed dependencies, though smooth VS Code integration is still unclear.

PEP 723 Design: Explicit Dependencies vs Inference

  • One commenter finds it redundant to both uv add --script and maintain an explicit dependency block.
  • Others explain PEP 723 deliberately avoids inferring from import because:
    • Imports may refer to local code, be dynamic, or come transitively from other packages.
    • Package names differ from module names (pyyaml vs yaml).
    • Python’s philosophy favors explicit declarations; PEP 723 explicitly rejects inference.

Python Ecosystem & Rustification Sentiment

  • Several strongly positive reports: uv “makes Python fun again,” simplifies scripts, and may replace conda + poetry flows.
  • One commenter sees Python packaging as chaotic and avoids anything outside distro repositories; others argue uv is a genuine step-change, not just another failed tool.
  • There’s tension around “rustification”:
    • Concerns about layering a large Rust ecosystem on top of Python, complicating hacking on tools and portability (especially in embedded or constrained environments).
    • Counterpoints that Rust-based tools like uv, Ruff, etc. dramatically improve performance and UX, and most developers never patch tooling anyway.
    • Some discomfort with the culture of attributing all improvements to “written in Rust,” and with Python tooling increasingly not being written in Python.

HTTP Clients and the Standard Library

  • A side thread criticizes the need for third-party HTTP clients (httpx/requests) for simple scripts, calling it a failure of the stdlib.
  • Others respond that http.client/urllib.request are usable, and people choose requests/httpx for ergonomics, async support, and history.
  • Debate about why stdlib docs recommend third-party libraries; historical inertia and Python’s age are cited.
  • Broader reflection: Python balances heavy backward-compat baggage with reluctance to add new batteries, pushing more functionality into third-party packages that must be managed by tools like uv.