Rye và uv: Tháng 8 là mùa thu hoạch của Python Packaging

Suy nghĩ và bài viết của Armin Ronacher

Rye và uv cho Python packaging: Tháng 8 là mùa thu hoạch

• Vài tháng trước, quyền quản lý công cụ đóng gói Rye đã được chuyển cho Astral
• Trong vài tháng qua, đội ngũ Astral đã phát triển nhiều công cụ cho Python packaging
• Trong các bản phát hành gần đây, uv đã bổ sung các tính năng như thao tác với tệp pyproject.toml, hỗ trợ workspace, tham chiếu gói cục bộ và cài đặt script
• uv cũng có thể quản lý cả việc cài đặt Python nên trở nên rất giống với Rye
• Những người đang dùng Rye nên chú ý đến uv và gửi phản hồi

Bài phát biểu tại EuroPython

• Gần đây tại EuroPython diễn ra ở Prague, ông đã trình bày quan điểm của mình về Python packaging và những bài học rút ra khi tạo ra Rye
• Mục tiêu của một công cụ packaging là trở thành công cụ tốt nhất mà mọi người đều sử dụng
• Python đã trở thành một nền tảng cực kỳ phổ biến nhờ vào đầu tư và sự quan tâm dành cho AI và ML
• Ông muốn những người học Python sẽ nhớ về một trải nghiệm phát triển tuyệt vời
• Hiện tại điều đó vẫn khó khăn do có quá nhiều công cụ và sự thiếu nhất quán

Sự thống trị của công cụ

• Sự thống trị có nghĩa là phần lớn đầu tư sẽ đổ vào một stack duy nhất
• Những công cụ như Rye nên biến mất khi một công cụ thống trị được xác lập
• uv nhiều khả năng sẽ trở thành công cụ đó
• Cuối cùng, Rye sẽ được thay thế bằng uv

Sự phát triển của hệ sinh thái packaging

• Nhiều công cụ packaging được xây dựng dựa trên sự phát triển của hệ sinh thái Python
• Đã có rất nhiều tiến bộ như chuyển từ tệp setup.py sang eggs và wheels, cũng như việc đưa vào các tiêu chuẩn metadata
• Sự phát triển của Rust crates và các thư viện Python đã giúp những công cụ này trở nên khả thi

Bước tiếp theo của cộng đồng

• Cộng đồng nên khuyến nghị ít công cụ hơn
• Đã từng có thời mọi người khuyến nghị ez_setup.py và easy_install
• Hiện nay, người ta khuyến nghị pip, pip-tools, poetry, PDM, v.v.
• Những người đang duy trì các dự án Python quan trọng nên thử uv và cân nhắc có nên khuyến nghị nó hay không

Nguồn vốn VC của Astral

• Cần suy nghĩ về việc Astral nhận vốn VC sẽ ảnh hưởng thế nào đến tương lai
• Nhìn vào mã nguồn và các tính năng của uv, ngay cả trong kịch bản xấu nhất thì cộng đồng vẫn sẽ tốt hơn so với trước khi uv tồn tại

Tóm tắt của GN⁺

• Bài viết này bàn về sự phát triển của các công cụ Python packaging và vai trò của cộng đồng
• uv cung cấp nhiều tính năng và rất có thể sẽ thay thế Rye
• Cộng đồng nên khuyến nghị ít công cụ hơn và cần thử dùng uv
• Cần cân nhắc tác động của nguồn vốn VC của Astral đối với tương lai
• Các công cụ có chức năng tương tự gồm có pip, poetry, PDM, v.v.

[GN⁺]

Ý kiến trên Hacker News

• Bản phát hành mới nhất của uv đã rút ngắn đáng kể quy trình phát hành của Home Assistant

  • Thời gian phát hành giảm từ khoảng 2,5 giờ xuống còn khoảng 20 phút
  • Có thể xem chi tiết trên blog dành cho nhà phát triển của Home Assistant

• Ban đầu đã kỳ vọng công cụ mới sẽ giải quyết vấn đề "packaging" của Python, nhưng thực tế nó nói về quản lý gói

  • Cá nhân tôi không thấy quản lý gói của Python có vấn đề quá lớn
  • pip nhìn chung hoạt động tốt

• Việc không thể dễ dàng đóng gói ứng dụng Python thành tệp thực thi là một điều bất tiện

  • Trong môi trường production, thường xuyên thấy việc git clone rồi tạo virtualenv
  • Điều này không tốt dưới góc độ bảo mật

• Python packaging có vấn đề, nhưng với pip mặc định thì mọi thứ vẫn hoạt động khá ổn

  • Việc chuyển từ virtualenv sang mô-đun venv tích hợp sẵn vốn là thay đổi lớn
  • Nếu muốn quản lý phụ thuộc một cách nghiêm túc, tốt hơn là xây dựng monorepo như FAANG

• Vì vụ lừa đảo VC quanh npm, thương vụ Microsoft mua lại, và tình trạng phi lợi nhuận về mặt pháp lý của OpenAI, tôi ngại giao hạ tầng ngôn ngữ cốt lõi cho các tổ chức như vậy

  • Các cá nhân đóng góp thì rất tuyệt, nhưng sự đồng bộ lợi ích tài chính ở cấp tổ chức mới là vấn đề
  • Lint nhanh, kiểm tra kiểu, quét mã và trợ lý PR có thể thay thế bất cứ lúc nào, nhưng luồng cài đặt và kho lưu trữ gói thì không

• Vấn đề của các công cụ này là tính chính danh

  • Chúng khác với cargo vì không nhận được sự phê chuẩn từ pypa
  • pypa đã không thể đưa ra một giải pháp toàn diện
  • Chỉ mới 3-4 năm trước, poetry và pipenv còn có vẻ như sẽ giải quyết được vấn đề
  • pypa nên tham gia vào astral.sh, nhưng không rõ liệu có thể làm vậy mà không kiểm soát hay không

• Armin cho rằng uv nên thống trị lĩnh vực này, nhưng cũng thừa nhận có thể phát sinh vấn đề vì được VC hậu thuẫn

  • Giải pháp của ông là uv rất dễ fork
  • Tuy nhiên, fork lại dẫn tới nhiều phân mảnh hơn

• Ở công ty, chúng tôi đang cố gắng migrate phần mềm sang uv vì poetry quá chậm

  • Tôi đã đọc rất nhiều tài liệu, nhưng thực tế chưa làm được bao nhiêu
  • Trước đây việc migrate sang poetry đơn giản hơn nhiều
  • uv vẫn giữ lại nhiều vấn đề của Python packaging

• Có thể hiểu được vì sao mọi người bỏ qua vòng này và chờ đến năm 2026 với "Trình quản lý gói Python: lần này thật sự đã giải quyết được rồi!"

  • Người dùng Nix dường như vẫn hài lòng

• Có những người thực sự đam mê việc phát triển trình quản lý gói

  • Nếu tình hình này tiếp diễn, mỗi năm sẽ lại có một trình quản lý gói mới xuất hiện