Một năm dùng uv: ưu, nhược điểm và những điều cần cân nhắc khi di chuyển

• Sau một năm dùng uv trong nhiều môi trường khách hàng, công cụ này đơn giản hóa đáng kể việc khởi tạo dự án Python và quản lý dependency; nếu môi trường cho phép thì rất đáng thử trước
• Gần như vẫn giữ được workflow pip/venv hiện có nhưng chạy nhanh và ổn định hơn, nên chi phí di chuyển tương đối thấp
• Gom việc cài Python, virtual environment, lock file, chạy lệnh, build và chạy công cụ tạm thời vào một công cụ duy nhất, qua đó giảm mạnh chi phí thử nghiệm dự án
• Tuy nhiên vẫn có các hạn chế thực tế: lỗi resolve dependency với dự án legacy, phạm vi hỗ trợ của python-build-standalone, cache có thể phình lên hơn 20GB, chính sách bảo mật doanh nghiệp và rào cản CLI
• Nếu tiếp tục làm việc với Python, dù dùng uv bạn vẫn cần biết pip và venv, để chuẩn bị cho những môi trường không cho phép dùng uv hoặc không phù hợp với uv

---

Điểm khởi đầu khiến dự án Python trở nên khó khăn

• Gốc rễ của vấn đề lớn nhất trong Python nằm ở việc bootstrap: chuẩn bị chính Python và bắt đầu một dự án mới
• Nhiều vấn đề đóng gói gặp phải về sau cũng bắt nguồn từ việc cài Python ban đầu và thiết lập dự án, hơn là từ bản thân việc cài dependency hay build package
• Cách cài Python khác nhau theo từng OS, với các giá trị mặc định và cạm bẫy cũng khác nhau
• Dù là ngôn ngữ phù hợp cho người mới, để cài Python vẫn cần biết trước khá nhiều kiến thức
• Python được dùng bởi rất nhiều nhóm rất khác nhau: sinh viên, nhà khoa học dữ liệu, lập trình viên AI, lập trình viên web, quản trị hệ thống, nhà sinh học, nhà địa lý học, lập trình viên plugin, v.v.
• Sự khác biệt môi trường chạy rất lớn — máy Windows của công ty, laptop cá nhân Debian, trường đại học, cơ quan hành chính, startup, quân đội, viện nghiên cứu, tập đoàn lớn — nên khó có một tutorial bao quát được tất cả
• PATH, PYTHONPATH, nhiều phiên bản Python cùng tồn tại, các package tùy chọn trên Linux, Python như một dependency hệ thống, và độ phổ biến của extension cần compile đều làm tăng độ phức tạp
• Một công cụ quản lý dự án Python tốt cần thỏa các điều kiện sau
  • Hoạt động độc lập với quá trình bootstrap Python
  • Thống nhất việc cài và chạy Python xuyên nền tảng và bối cảnh
  • Đóng vai trò cầu nối với các công cụ cơ bản như pip và venv
  • Có dependency resolver mạnh
  • Xử lý dễ dàng các cài đặt đơn giản, đồng thời làm được các việc phức tạp như cài dependency đã lock trên OS khác
  • Dễ cài, dễ dùng và đủ đáng tin cậy để giao phó một phần quan trọng của stack

Cách uv bootstrap

• uv được cài đặt và cập nhật hoàn toàn độc lập với Python; việc cài uv và cài Python không ảnh hưởng lẫn nhau
• Các vấn đề bootstrap Python, vấn đề PATH, vấn đề import không ảnh hưởng tới bản thân uv
• Giảm bớt sự nhập nhằng như nên đặt vị trí cài trong hệ thống hay trong virtual environment, hoặc keyword mới hay việc loại bỏ tính năng trong Python sẽ ảnh hưởng gì đến uv
• uv trước tiên cung cấp interface pip và venv, để có thể dùng cùng các dự án, công cụ và cách nghĩ hiện có
  • Đây là lựa chọn có cân nhắc tới cộng đồng hiện tại và mã legacy
  • Người dùng có thể dùng uv như workflow pip·venv hiện có mà không cần học uv run, uv add, uvx
  • Chỉ riêng tốc độ và độ tin cậy trong các tác vụ cơ bản cũng đã tạo lý do để migrate
• uv cũng cung cấp chức năng cài Python
  • Cài theo một cách thống nhất trên mọi OS
  • Không cần quyền admin
  • Hoạt động độc lập với Python hệ thống
  • Cài nhiều phiên bản mà không xung đột
  • Cung cấp cùng một standard library và có cả tkinter
  • Bao gồm cả các phiên bản Pypy, No-GIL, TCO
  • Hoạt động không cần shim, compile hay các mặc định phi lý

Trải nghiệm cài Python và python-build-standalone

• Ví dụ uv python install pypy3.8 cài Python 3.8.16 chỉ trong 2,71 giây
• Cách tương tự cũng chạy được trên Mac hoặc Windows
• Không xuất hiện các package bị thiếu liên quan đến Tcl, OpenSSL, Gzip; xung đột với nguồn cài Python khác; mô hình khác nhau theo OS; lệnh bị thiếu; hay PATH cấu hình sai
• Việc cài Python của uv dùng python-build-standalone, và Astral đã tiếp quản dự án này để cải thiện nó
• Astral đang cố gắng đưa các lợi ích đó trở lại upstream cPython, đồng thời cũng đã đóng góp cho các dự án mã nguồn mở lân cận

Chức năng quản lý dự án

• uv init mặc định tạo .venv, pyproject.toml, một git repository có .gitignore cho Python, README.md và hello.py
• Dependency gốc có thể được khai báo trong pyproject.toml hoặc thêm bằng uv add
• uv remove dọn repository đúng cách
• uv lock --upgrade-package <package>==<version> cho phép nâng cấp package từng phiên bản một cách thận trọng
• uv build tạo package .whl từ dự án, nhưng uv không bắt buộc dự án phải có khả năng build
• uv run chạy lệnh bên trong virtual environment ngay cả khi virtual environment chưa được activate
  • Người dùng không cần biết đến sự tồn tại của virtual environment hay khái niệm activate
• Các lệnh này tự động và minh bạch cập nhật lock file
  • Vì uv nhanh nên gần như không cảm nhận được việc cập nhật diễn ra
  • Người dùng không cần biết lock file là gì
• Lock file là cross-platform, nên có thể phát triển trên Windows và deploy lên Linux

Hiệu năng, độ ổn định và thông báo lỗi

• Hiệu năng của uv làm giảm chi phí cài dependency và thử nghiệm dự án
• Có thể bắt đầu lại rất nhanh, nên dễ lặp lại nhiều thử nghiệm mà không thấy nặng nề
• Các công cụ như pyenv, pipenv, poetry từng bị vỡ với stack trace trong nhiều môi trường, nhưng uv hoạt động rất vững
• Về chất lượng của Astral, có ba điểm đặc biệt nổi bật
  • Sửa lỗi nhanh và phản hồi tích cực với feedback, report
  • Văn hóa testing mạnh, đồng thời cung cấp bộ test dependency resolution dưới dạng package riêng
  • Thông báo lỗi rất tốt
• Ví dụ uv add httpie==2 cho thấy từng bước rằng httpie==2.0.0 phụ thuộc vào requests>=2.22.0, nhưng dự án lại phụ thuộc vào requests==1, nên các yêu cầu không thể được thỏa mãn
• Thông báo lỗi dependency resolution cũng chịu ảnh hưởng từ pubgrub, nhưng thông báo lỗi trên toàn uv đều đi theo cùng hướng đó
• Khi dùng uv trong môi trường giảng dạy, sinh viên có thể làm việc hiệu quả mà không cần can thiệp nhiều; với các công cụ khác chưa từng có trải nghiệm như vậy
• Các dự án chuyên nghiệp mới dễ dàng hưởng lợi từ uv, nhưng với dự án legacy có thể xuất hiện yếu tố chặn

uvx và cách sử dụng mới

• uv cung cấp các primitive mạnh và nhanh để chuẩn bị, cô lập Python và dependency
• Trước đây việc chuẩn bị Python và dependency là một ràng buộc chậm và dễ vỡ, nhưng trong uv có thể xem nó như một tính năng để điều chỉnh workflow
• uv run --with jupyter jupyter notebook chạy Jupyter trong dự án hiện tại nhưng không thêm Jupyter và dependency của nó vào dự án
• uvx --with pendulum -p 3.13t python tải xuống và cài một bản build Python No-GIL mới, tạo virtual environment tạm thời, cài pendulum, rồi khởi động Python shell
• uvx là công cụ giống npx cho Python, có thể xem như một phiên bản pipx được làm đúng
• Hỗ trợ dependency inline thay đổi cách dùng dependency trong các script Python nhỏ
  • Trước đây với script nhỏ, thường phải tránh dependency hoặc dùng các workaround phiền phức
  • Giờ có thể dùng dependency theo cách nhanh, minh bạch và tự mô tả
• Các tính năng này không bị áp đặt, nên người dùng có thể tự khám phá và áp dụng khi cần

Những điểm uv thất bại hoặc gây bất tiện

• uv không thể giải quyết thay các vấn đề đóng gói thực sự
  • Các vấn đề như version marker sai, thiếu wheel, xung đột tên nằm ngoài tầm kiểm soát của uv
  • Những vấn đề này vốn nằm trong chất lượng dữ liệu trên PyPI
  • Lý do vấn đề đóng gói có vẻ giảm đi trong uv là vì uv xử lý đúng các phần khác
• Do dependency resolver nghiêm ngặt hơn, virtual environment của các dự án legacy từng dựa vào cách resolve lỏng lẻo của pip cũ có thể bị vỡ
  • Trong một trường hợp codebase 15 năm tuổi vừa migrate sang Python 3 và đứng trên lịch sử pip freeze chưa được dọn dẹp, uv đã không hoạt động
• Trình cài Python tích hợp của uv bị giới hạn ở các phiên bản build bằng python-build-standalone
  • Trình cài từ python.org, deadsnake, pyenv có thể cài nhiều phiên bản Python hơn
  • Đây có thể là vấn đề với dự án cũ bắt buộc cần một phiên bản Python cụ thể
  • uv vẫn hoạt động tốt với Python cài từ bên ngoài, nên đây không phải yếu tố chặn hoàn toàn
• File thực thi python-build-standalone có thể hơi chậm hơn
  • Theo pyperformance, Python 3.10 của uv chậm hơn Python của Ubuntu 3%
  • Có thể bạn sẽ muốn dùng Python được compile tối ưu cho phần cứng
• Dung lượng cache cũng có thể là nhược điểm
  • Sau một năm sử dụng, cache uv chiếm hơn 20GB trên đĩa
  • Có thể xóa bằng uv cache clean, nhưng như vậy sẽ mất lợi thế tốc độ
  • Khác với pip, uv hard link package để chỉ chiếm dung lượng một lần, nên vẫn có khả năng ít hơn tổng dung lượng của nhiều virtual environment trước đây
• $UV_PYTHON có bất tiện là ép phiên bản Python thay vì cung cấp phiên bản mặc định, và issue liên quan đang được xử lý
• uv là mã nguồn mở nhưng là sản phẩm của công ty thương mại Astral
  • Astral hiện chưa có lãi và cũng chưa công bố sản phẩm thương mại
  • Có ý kiến cho rằng cần thận trọng trước khi giao phó một phần quan trọng của stack
  • Ngược lại, chi phí chuyển sang uv và chi phí rời khỏi uv đều thấp
• Hạn chế lớn nhất là việc áp dụng trong doanh nghiệp
  • Trong môi trường tập đoàn lớn có bảo mật chặt và bị khóa, việc cài dependency mới rất khó
  • Nếu bộ phận bảo mật IT kiểm soát những gì có thể làm trên máy, họ có thể không cho phép cài uv
  • Cho đến khi đạt bản ổn định và đáp ứng nhiều yêu cầu, uv sẽ còn bị hạn chế lớn trong môi trường doanh nghiệp
• CLI cũng là một rào cản
  • Không ít người dùng Python không quen command line, đặc biệt là người dùng Windows
  • Đây cũng là một trong những lý do Anaconda có GUI
  • Yêu cầu dùng công cụ CLI là rào cản gia nhập với người mới hoàn toàn
• uvx và uv tool install khuyến khích cài công cụ bên ngoài dự án giống pipx
  • Phù hợp với các công cụ độc lập như yt-dlp, httpie
  • Với công cụ phát triển nhạy cảm với phiên bản Python hoặc cú pháp thư viện như mypy, nếu cài vào phiên bản Python khác với dự án thì có thể gây vấn đề

Khi nào nên tránh uv

• Có năm tình huống không nên dùng uv
  • Có dự án legacy không chạy được với dependency resolution của uv, và bạn không có khả năng hoặc không muốn dọn dẹp để migrate
  • Môi trường doanh nghiệp không cho phép dùng uv
  • Không tin tưởng vì uv chưa phải bản ổn định, sản phẩm thương mại của Astral chưa ra mắt, hoặc nhóm contributor Rust còn nhỏ
  • Cần một phiên bản Python cụ thể mà uv không cung cấp, và không muốn dùng uv cùng Python cài bên ngoài
  • CLI là trở ngại quá lớn đối với đội ngũ
• Vấn đề niềm tin và vấn đề phiên bản Python cụ thể giống lựa chọn hơn là rào cản kỹ thuật
• Với hạn chế môi trường doanh nghiệp, người dùng không thể làm được nhiều
• Trọng tâm thực sự cần cân nhắc là dependency legacy và rào cản CLI
• Lời khuyên rất đơn giản
  • Luôn thử uv trước
  • Nếu không chạy, quay lại cách cũ hoặc tìm workaround
• Nếu CLI là vấn đề, có thể dùng trình cài python.org để chuẩn bị Python và đề xuất plugin IDE bọc uv
• Người có thể lập trình nhiều khả năng sẽ học được nền tảng command line cần thiết để dùng uv

Vị trí trong tương lai

• Để dùng trong môi trường doanh nghiệp vẫn còn khoảng cách tới v1, và vì doanh nghiệp khó cập nhật thường xuyên nên bản ổn định rất quan trọng
• Có thể kỳ vọng các tính năng bundling thay thế pex/shiv và build backend sẽ được bổ sung
• Chức năng tạo installer cho ứng dụng trông như kết luận logic, nhưng phức tạp hơn nhiều vì chỉ riêng việc ký số cũng đã khó xử lý đúng
• Khi hỗ trợ task được hoàn thiện, với nhu cầu cá nhân thì bộ tính năng sẽ đủ
• Nếu Python là công việc của bạn, bạn vẫn cần học cách dùng pip và venv
  • Vì một lúc nào đó bạn có thể gặp tình huống không dùng được uv
• Tóm lại, uv có chi phí thấp và lợi ích lớn, nên trong môi trường có thể dùng, đây là một giải pháp Pareto đáng thử trước