Switching Pip to Uv in a Dockerized Flask / Django App

Original Article ↗ Hacker News Discussion ↗

uv workflow and capabilities

  • uv can replace pyenv, virtualenv, and pip: pin Python versions, create .venv, install via uv pip install -r requirements.txt, and run commands with .env support.
  • It can infer Python version from requires-python in pyproject.toml, with .python-version or --python overriding.
  • Several people report dramatic speedups over pip (minutes → tens of seconds), though others only see ~2x improvements and note network or dependency complexity can dominate.
  • Some users find uv ergonomically better than pyenv/poetry/pip and appreciate features like uv run --with for trying dependencies.

Lockfiles, CI, and reproducibility

  • A major subthread debates a shell snippet that auto-runs uv lock when uv.lock is missing or invalid.
  • Critics argue this undermines the purpose of a lockfile: CI should never silently rewrite it; missing or outdated locks should be a hard failure requiring human intervention.
  • Others note that many Python projects historically didn’t use or commit lockfiles correctly; they see uv’s “locked by default” workflow as a big improvement.
  • Broader discussion covers:
    • Libraries vs applications: some say only apps should commit lockfiles; others argue all projects should for reproducible CI.
    • Using uv sync --locked to ensure builds fail if the lock is missing or out-of-date.
    • Disagreement over whether CI should ever generate a fresh lockfile.

requirements.txt, pyproject.toml, and dependency workflows

  • Some object to dropping requirements.txt, preferring:
    • High-level deps in requirements.in/pyproject.toml.
    • A compiled, fully pinned requirements.txt generated via pip-compile/uv.
  • Others respond that pyproject.toml already plays the “high-level requirements” role and uv’s lockfile is the install snapshot.
  • Multiple patterns are discussed: requirements.in → requirements.txt, or pyproject.toml + lockfile, with emphasis on clarity about which file is authoritative.

Security considerations

  • One commenter asks for a security comparison of uv, pip, conda, etc., stressing security over speed.
  • Replies note pip can execute arbitrary code in setup.py when installing source distributions; newer pip options can avoid this but are non-default.
  • uv is described as resolving dependencies without executing arbitrary code and verifying hashes by default, though others argue that all ecosystems ultimately run untrusted third-party code.

Docker integration and best practices

  • The article’s Docker pattern prompts feedback:
    • Concerns about copying uv from a floating image tag instead of a pinned digest.
    • Suggestions to install into standard global paths in containers to ease debugging and avoid uv-specific layouts.
    • Preference for expressing build logic directly in Dockerfile RUN lines instead of shell scripts to reduce indirection.
  • Some advise keeping dev/test workflows independent of Docker Compose so CI platforms remain interchangeable.

uv vs pip/poetry and Python packaging “mess”

  • Several commenters praise uv as “one of the best things to happen” to Python packaging, with people abandoning pyenv, poetry, and raw pip for a single tool.
  • Others are tired of “yet another Python package manager”, referencing the long history of competing tools and incomplete solutions.
  • A few say they’ve never had problems with simple requirements.txt + venv setups and don’t see the “mess”.

Language choice (Rust vs Python/C) for tooling

  • One commenter strongly opposes Python tooling written in Rust, citing:
    • Reduced contributor pool vs C, which many Python devs already know.
    • An example Rust-based library (Pendulum) lagging on Python 3.13 support.
  • Counterarguments:
    • uv’s speed, concurrency, and single-binary distribution are cited as clear wins.
    • Having tooling outside Python avoids bootstrapping issues and environment conflicts.
    • Many users don’t care what language tools are written in so long as they’re reliable and fast.
  • Some downplay the “10x faster” narrative, reporting modest gains over poetry, but still consider uv’s ergonomics the main attraction.

Adoption, ecosystem, and business concerns

  • Library authors worry about debugging user issues if uv’s behavior diverges from pip; uv’s own docs list intentional differences.
  • Questions are raised about Astral’s business model and whether uv might follow a trajectory similar to Anaconda; this is left largely unresolved.
  • There’s skepticism about switching all projects yet again vs waiting to see if uv remains maintained for years.

Practical gotchas and tips

  • uv doesn’t compile .pyc files by default; replacing pip with uv in containers without enabling bytecode can slow startup.
  • Official docs describe how to enable bytecode compilation in Docker images.
  • uv isn’t in common apt repos; suggestions include:
    • Copying the uv binary from the official container image (ideally pinned by version/SHA).
    • Installing uv via pip in Docker.
  • Some report uv-specific snags (e.g., environment variables with Django) and hope guides like the article will help.
  • Others propose a hybrid approach: use uv to generate a frozen requirements.txt and continue installing with pip inside Docker.