Lời kêu gọi ngừng sử dụng uv-build làm build backend

Việc chọn một build backend cho các gói Python tưởng chừng chỉ là chi tiết kỹ thuật nhỏ, nhưng lại có thể gây ra những hệ quả dây chuyền đáng kể đối với cộng đồng mã nguồn mở. Đó là vấn đề mà một nhà phát triển của Gentoo vừa lên tiếng cảnh báo.

uv-build là gì và tại sao lại gây tranh cãi?

Trong hệ sinh thái Python, build backend là thành phần chịu trách nhiệm chuyển đổi mã nguồn thành gói phân phối (wheel hoặc source distribution). Chuẩn PEP 517 cho phép nhà phát triển tự do lựa chọn backend mà không bị ràng buộc với bất kỳ công cụ frontend nào.

uv-build là backend do Astral phát triển, được viết bằng Rust. Bản thân uv và các công cụ khác của Astral như uv hay ruff đều được đánh giá cao nhờ chất lượng và sự phản hồi nhanh từ đội ngũ phát triển. Tuy nhiên, việc dùng uv-build làm backend cho các gói Python thuần túy lại là câu chuyện hoàn toàn khác.

Tác giả bài viết không phản đối uv hay các công cụ khác của Astral. Vấn đề nằm ở chỗ lợi ích mà uv-build mang lại không tương xứng với những bất lợi mà nó gây ra cho hệ thống đóng gói.

Kích thước và chi phí biên dịch

Một trong những vấn đề lớn nhất là kích thước. Tính đến phiên bản 0.13.0, wheel của uv-build có dung lượng từ 1,2 MiB đến 1,5 MiB tùy theo nền tảng. So sánh với flit-core — một backend Python thuần túy — chỉ nặng 45 KiB, có thể thấy sự chênh lệch lên tới hàng chục lần.

Đối với người dùng Gentoo, điều này đồng nghĩa với việc họ phải biên dịch uv-build từ mã nguồn thay vì sử dụng wheel có sẵn. Vấn đề càng nghiêm trọng hơn khi uv-build được phát hành với tần suất rất cao: 12 phiên bản trong vòng 30 ngày trước thời điểm bài viết được đăng tải.

Mỗi 100 mili-giây để chạy uv-build và cài đặt một phiên bản gói của bạn, người dùng Gentoo sẽ phải dành hàng giờ để biên dịch các phiên bản uv-build mới lặp đi lặp lại.

Vấn đề tương thích nền tảng

Tuy nhiên, thời gian biên dịch chưa phải là vấn đề nghiêm trọng nhất. Khả năng tương thích nền tảng mới là điều đáng lo ngại hơn cả.

Python có thể chạy trên hầu hết các nền tảng chỉ cần có trình biên dịch C hoạt động. Trong khi đó, danh sách nền tảng mà Rust hỗ trợ lại mở rộng một cách chậm chạp. Ngay cả khi có thể cài đặt trình biên dịch Rust trên một nền tảng nhất định, uv vẫn có thể không hoạt động được.

Các vấn đề có thể kể đến bao gồm:

• Lỗi trong các gói phụ thuộc mà uv sử dụng. Ví dụ, thư viện rustix::fs và các thành phần liên quan bỏ qua nền tảng SPARC mà không có lý do rõ ràng.
• Kích thước tệp thực thi quá lớn khiến toolchain cạn kiệt không gian địa chỉ. Khác với bộ nhớ hệ thống, không gian địa chỉ không thể mở rộng tùy ý. Gói ebuild của uv trên Gentoo hiện đã phải mang theo hai bản vá chỉ để có thể biên dịch trên nền tảng 32-bit.
• Việc bổ sung và duy trì một nền tảng mới gần như là một công việc toàn thời gian, kèm theo vô số khó khăn khi mã nguồn liên tục thay đổi.

Hai lý lẽ ủng hộ uv-build và phản hồi

Tác giả bài viết thừa nhận có hai lý do chính để chọn uv-build làm backend.

Thứ nhất là tính nhất quán khi đã dùng uv cho dự án. Lập luận này không thực sự thuyết phục, bởi bản chất của PEP 517 là cho phép dùng bất kỳ backend nào với bất kỳ công cụ nào. flit-core hay hatchling đều hoạt động tốt với uv hoặc bất kỳ frontend nào khác.

Thứ hai là hiệu năng. Lập luận này càng ít cơ sở hơn khi chênh lệch thực tế chỉ ở mức khoảng 100 mili-giây cho một thao tác hiếm khi được thực thi. Trong nhiều trường hợp, khoản lợi này còn bị thời gian tải wheel 1,5 MiB của uv-build vượt qua.

Điểm mấu chốt là backend này trên thực tế chỉ được dùng bởi nhà phát triển dự án, người đóng góp, quy trình CI/CD, nhà đóng gói downstream và người dùng source distribution. Tất cả người dùng thông thường đều cài đặt qua wheel. Trong số này, nhóm người dùng source distribution là đông đảo nhất và chịu ảnh hưởng nhiều nhất — và mọi lợi ích về hiệu năng đều bị xóa sổ bởi thời gian biên dịch uv-build.

Ý nghĩa với cộng đồng Python Việt Nam

Với các nhà phát triển Python tại Việt Nam, đặc biệt là những người tham gia đóng gói phần mềm mã nguồn mở hoặc duy trì các bản phân phối Linux, bài viết này là lời nhắc nhở về tầm quan trọng của việc cân nhắc kỹ lưỡng khi lựa chọn công cụ.

Việc chọn build backend nhẹ và tương thích rộng như flit-core hay setuptools không chỉ giúp giảm gánh nặng cho hệ thống đóng gói mà còn đảm bảo phần mềm của bạn tiếp cận được nhiều nền tảng hơn, bao gồm cả các kiến trúc ít phổ biến như ARM32 hay RISC-V đang ngày càng được sử dụng trong các thiết bị IoT và máy chủ tại Việt Nam.

Cuối cùng, đây không phải là vấn đề "công nghệ nào tốt hơn" mà là bài toán cân bằng giữa lợi ích cục bộ của dự án và chi phí mà cộng đồng phải gánh chịu.