Rye và uv: Tháng 8 là mùa thu hoạch của đóng gói Python
(lucumr.pocoo.org)- Sau khi quyền quản lý Rye được chuyển cho Astral vào tháng 2 năm 2024, uv — resolver và installer nền tảng của nó — đã được cải tiến rất nhanh và nổi lên như ứng viên để hợp nhất các công cụ đóng gói Python
- uv mới nhất hiện bao gồm cả thao tác với
pyproject.toml, hỗ trợ workspace, tham chiếu gói cục bộ, cài đặt script và quản lý cài đặt Python, qua đó hấp thụ dần phạm vi mà Rye từng đảm nhiệm - Nhờ đầu tư vào AI·ML, số người dùng Python mới tăng lên, nhưng vì có quá nhiều lựa chọn công cụ đóng gói và mức độ tương thích không đồng đều, trải nghiệm nhà phát triển vẫn chưa nhất quán
- Hệ sinh thái đóng gói cần một công cụ thống trị mà ai cũng dùng, để đầu tư và tài liệu cùng hội tụ vào một stack; Rye nhiều khả năng sẽ trở thành con đường di trú để chuyển sang lấy uv làm trung tâm
- Khoản đầu tư VC của Astral là một rủi ro mà PSF và các dự án lõi của Python cần cân nhắc, nhưng uv được đánh giá là mã nguồn vẫn có thể fork và duy trì ngay cả trong kịch bản xấu nhất
Dòng chảy chức năng từ Rye sang uv
- Vào tháng 2 năm 2024, quyền quản lý Rye được chuyển cho Astral, và trong những tháng sau đó Astral đã cải tiến nhanh các công cụ đóng gói Python
- Người dùng Rye có thể cảm nhận rằng uv — resolver và installer nền tảng — đã tốt hơn và nhanh hơn
- uv mới nhất bắt đầu trực tiếp cung cấp những tính năng trước đây cần đến Rye
- thao tác với tệp
pyproject.toml - hỗ trợ workspace
- tham chiếu gói cục bộ
- cài đặt script
- quản lý cài đặt Python
- thao tác với tệp
- Những người hiện đang dùng Rye nên xem thử uv và gửi phản hồi cho Astral
Vì sao các công cụ đóng gói Python cần hội tụ về một nơi
- Bài trình bày tại EuroPython Prague tập trung vào tình hình hiện tại của đóng gói Python và những bài học rút ra khi tạo ra Rye
- Mục tiêu của công cụ đóng gói là trở thành công cụ thống trị trong lĩnh vực đó
- Công cụ mà mọi người dùng nên là công cụ tốt nhất
- Vì đó là công cụ mà người mới tiếp cận Python sẽ gặp khi bắt đầu hành trình lập trình
- Trong 2 năm gần đây, nhờ đầu tư và sự quan tâm dành cho AI và ML, Python đã trở thành một nền tảng cực kỳ nóng và phổ biến với các nhà phát triển mới
- Điều quan trọng là người dùng mới ghi nhớ Python như một ngôn ngữ có trải nghiệm nhà phát triển xuất sắc, chứ không phải một ngôn ngữ cũ kỹ với công cụ tệ
- Nhưng hiện tại, mảng đóng gói Python có quá nhiều lựa chọn, khả năng tương thích giữa các công cụ chưa hoàn toàn đầy đủ, và những bất nhất ở nhiều nơi làm rung lắc trải nghiệm
- Có người dùng đi theo một công cụ rồi đụng tường, chuyển cả stack sang conda, rồi lại quay trở lại
Khả năng uv trở thành công cụ thống trị
- Khi một công cụ giữ vị trí thống trị, điều đó có nghĩa là phần lớn đầu tư sẽ tập trung vào một stack duy nhất
- Với Rye và nhiều công cụ xung quanh nó, sẽ là hướng đi đáng mong muốn nếu khi công cụ thống trị được xác lập, chúng không còn cần tồn tại độc lập nữa
- Hiện tại uv được đánh giá là công cụ có khả năng lớn nhất để đảm nhận vai trò đó
- Nó vẫn chưa đáp ứng mọi trường hợp sử dụng
- Tuy vậy, có vẻ nó sẽ nhanh chóng đạt đến điểm đó
- Đây là thời điểm cộng đồng nên bắt đầu tập hợp quanh uv
- Điều này không có nghĩa công cụ này sẽ mãi mãi là công cụ duy nhất
- Công cụ có thể xuất hiện rồi biến mất
- Trong tương lai có thể sẽ có công cụ khác xuất hiện
Việc Rye nghỉ hưu và thay đổi trong hướng dẫn cho các dự án Python
- Bản phát hành cuối cùng được kỳ vọng của Rye sẽ cho nghỉ hưu các tính năng riêng của Rye, di trú người dùng sang uv, và hoạt động phần lớn như một bí danh của uv
- Chỉ cho Rye nghỉ hưu thôi là chưa đủ
- Hiện tại Python đang dùng nhiều lời giải quản lý gói khác nhau
- Cộng đồng cần hướng dẫn số lượng công cụ ít hơn
- Rye và uv được xây dựng trên nền tảng nhiều năm phát triển lâu dài của hệ sinh thái bên dưới
- dòng chuyển dịch từ
setup.pysang eggs, rồi sang wheels - dòng chuyển dịch từ chỗ thiếu chuẩn metadata sang có chuẩn
- dòng chuyển dịch từ hệ thống build gắn chặt sang hệ thống build tách rời
- những công việc giúp tạo ra các binary Python có thể phân phối lại và tải về
- hệ sinh thái các Rust crates và thư viện Python liên quan
- dòng chuyển dịch từ
- Cộng đồng cần sẵn sàng để một ngày nào đó nói rằng họ không còn khuyến nghị một số công cụ nữa
- Trước đây, tài liệu hướng dẫn cho nhà phát triển mới từng khuyến nghị
ez_setup.pyvàeasy_install - Sau đó, tài liệu đã loại bỏ
ez_setup.pyvà thay bằngpip - Một số dự án từng hướng dẫn
pip-tools,poetry,PDM - Hiện nay nhiều dự án thậm chí hiển thị đồng thời 5 cách cài đặt vì có quá nhiều công cụ khác nhau
- Trước đây, tài liệu hướng dẫn cho nhà phát triển mới từng khuyến nghị
- Những người bảo trì các dự án Python quan trọng nên trực tiếp dùng thử uv và đánh giá xem có thể hướng dẫn người dùng dùng uv hay không
- Bài viết của Charlie từ Astral về những gì uv hiện có thể làm cho thấy những thành quả hiện tại của uv
Khoản đầu tư VC của Astral và rủi ro với cộng đồng
- Việc Astral, công ty tạo ra uv, là một công ty nhận đầu tư VC là một điểm tranh luận không thể tránh khỏi
- Từ góc nhìn cộng đồng, việc ai đó rót rất nhiều tiền có thể tạo ra những thách thức mới
- PSF và các dự án lõi của Python cần cân nhắc điểm này
- Xét theo mã nguồn và cách uv vận hành, nó có vẻ là đối tượng vẫn có thể fork và duy trì ngay cả trong một tương lai tồi tệ nhất
- Dù Astral đóng cửa hoặc làm điều gì đó rất đáng ngờ về mặt giấy phép, cộng đồng vẫn có thể ở vị thế tốt hơn so với trước khi uv tồn tại
1 bình luận
Các ý kiến trên Hacker News
Bản phát hành mới nhất của uv cũng đã được thảo luận hôm qua: https://news.ycombinator.com/item?id=41302475
Bài được liên kết là quan điểm do tác giả Rye viết sau khi xem bản phát hành đó
Với những ai quan tâm đến uv, việc dùng uv thay cho pip đã khiến quy trình phát hành Home Assistant nhanh hơn rất nhiều
Thời gian phát hành giảm từ khoảng 2,5 giờ xuống còn khoảng 20 phút; chi tiết có tại https://developers.home-assistant.io/blog/2024/04/03/build-i.... Nói thêm là tôi chỉ là người dùng HA
Dù tôi chỉ dùng Python ở mức nhẹ, tôi cũng không biết rốt cuộc nó đang làm gì mà mất lâu đến vậy, và thấy điều đó thật vô lý
Tôi biết packaging của Python có vấn đề, nhưng cá nhân tôi đến giờ chỉ dùng plain pip cũng đã đi được khá xa
Thay đổi lớn nhất là chuyển từ virtualenv ban đầu sang mô-đun venv tích hợp sẵn. Nếu thật sự nghiêm túc về quản lý dependency, tôi có lẽ sẽ làm monorepo kiểu FAANG và tránh những rắc rối liên quan đến package manager
Tôi đang quản lý một monorepo Python trong môi trường production và quản lý dependency đúng là địa ngục. Tôi đang cố áp dụng một vài tính năng mới của Poetry, nhưng tình trạng hệ sinh thái quanh các monorepo lớn thì thật tệ hại
Mục tiêu không phải là “với tôi thì đủ”, mà là cần một công cụ chuẩn cho package và môi trường ảo có thể mở rộng từ tổ chức 2 lập trình viên Python cho đến quy mô hàng trăm, hàng nghìn người. Nếu không, hệ sinh thái sẽ bị phân mảnh, bug và tài liệu khó hiểu sẽ tăng lên, khiến ngôn ngữ khó tiếp tục phát triển một cách hiệu quả
Nhưng không có cách nào định nghĩa dự án được xây dựng nhắm tới phiên bản Python nào. Nếu bạn tạo package, rất có thể bạn phải test trên nhiều phiên bản; còn nếu đó không phải là package phân phối có thể cài đặt mà chỉ là một tập mã được vài lập trình viên chia sẻ, thì với các việc như chạy mô hình machine learning, triển khai cloud function hay tạo báo cáo, thường bạn sẽ muốn nhắm chính xác vào một phiên bản Python duy nhất
Tôi cũng không rõ cách tiếp cận monorepo có nghĩa là sao chép numpy và pandas vào repository hay không
Ban đầu tôi kỳ vọng công cụ mới sẽ giải quyết vấn đề “packaging” của Python, nhưng đọc thêm thì hóa ra nội dung nói về quản lý package hơn là vấn đề đóng gói ứng dụng Python do tôi viết
Cá nhân tôi không gặp vấn đề lớn với quản lý package trong Python; hệ sinh thái vẫn có điểm thiếu sót, nhưng ngoài những chuyện như không có namespace thì pip nhìn chung hoạt động tốt
Điều thật sự gây bực bội là không thể dễ dàng bọc một ứng dụng Python thành file thực thi rồi triển khai ở đâu đó. Tôi thường thấy người ta git clone và tạo virtualenv trong môi trường production, điều này đòi hỏi máy chủ đích phải có nhiều kết nối hơn mức cần thiết, và dependency phục vụ phát triển cũng có thể bị để lại trong hệ điều hành. Từ góc độ bảo mật, đó là một ý tưởng rất tệ, nên chừng nào vấn đề này chưa được giải quyết, tôi sẽ ưu tiên ngôn ngữ khác cho các công việc cần phân phối tới người dùng cuối hoặc triển khai production
Để làm được vậy, ứng dụng phải được chuyển đến người dùng, tìm được Python ở đó, và quá trình này phải minh bạch với người dùng. Một trong những lý do khi làm Rye, và uv cũng tương tự, là cố gắng hỗ trợ cài đặt Python theo cách không làm hỏng hệ thống
Hình thức tiến xa hơn là tự động hóa toàn bộ quy trình, bao gồm cả uv. Ngay bây giờ, nếu muốn, bạn vẫn có thể dùng trình cài đặt kiểu curl to bash để cài uv/Rye và ứng dụng vào một vị trí tạm thời riêng cho ứng dụng, đồng thời đảm bảo không bao giờ làm hỏng hệ thống của người dùng
Hy vọng một ngày nào đó quy trình này sẽ hoàn toàn minh bạch, không cần truy cập mạng, và thậm chí có cả thứ như .msi cho Windows. Tuy nhiên điều kiện tiên quyết là công cụ như uv phải có thể tùy ý đặt Python đã biên dịch sẵn và mọi dependency cần thiết vào vị trí phù hợp với nền tảng của người dùng
Phần thưởng cuối cùng mà uv có thể cung cấp một ngày nào đó là đầu ra được đóng gói hoàn chỉnh, và nếu vậy thì sẽ rất tuyệt. Chỉ riêng bước trước đó thôi cũng có thể khiến trải nghiệm cung cấp công cụ dòng lệnh viết bằng Python cho người dùng không còn kinh khủng nữa. Có thể dùng uvx, hoặc nếu muốn thì ẩn hoàn toàn bản thân uv
Ví dụ có các công cụ tạo trình cài đặt theo từng hệ điều hành, và cũng đã có công cụ để triển khai tới những nơi đặc thù như Android, iOS hay trình duyệt. Tất nhiên một package cụ thể có thể không hoạt động trên một mục tiêu cụ thể, nhưng vì có giao diện chuẩn, nếu mã có thể chạy ở đâu đó thì công cụ dành cho mục tiêu đó lẽ ra phải tạo được kết quả có thể hoạt động
Sau các vụ “rug pull” dựa trên vốn đầu tư mạo hiểm của npm, việc Microsoft mua lại, và OpenAI cho thấy ngay cả tư cách phi lợi nhuận về mặt pháp lý cũng chỉ là marketing yếu ớt đối với những nhà lãnh đạo bị cuốn vào con đường vốn đầu tư mạo hiểm, tôi trở nên e dè khi giao hạ tầng ngôn ngữ nằm trên đường găng cho các tổ chức như vậy
Những cá nhân đóng góp ở đó ai cũng giỏi, và thường là xuất sắc, nhưng lợi ích tiền bạc ở cấp tổ chức đã bị nhiễm bẩn ngay từ đầu. Sau 1–4 năm, điều quan trọng là tổ chức. Kiểu như “hoặc chết như một anh hùng, hoặc sống đủ lâu để trở thành phản diện”
Vì vậy các linter nhanh, kiểm tra kiểu, quét mã, công cụ hỗ trợ PR thì ổn và lúc nào cũng có thể thay thế. Nhưng luồng cài đặt và kho gói thì không
Nghĩ đến tình trạng của pip và conda thì thật đáng tiếc, nhưng tôi cho rằng thực tế là vậy
Tôi nghĩ Microsoft đang sở hữu Python, chỉ là không công khai lộ ra mà thôi
Vài năm trước tôi muốn tạo Python binding cho kubectl, nhưng phát hiện rằng để chạy đa nền tảng, CGo trên mọi nền tảng phải dùng cùng compiler với Python. Thế nhưng trên Windows, CGO dùng MINGW còn Python dùng MSVC. Tôi đã hỏi trên mailing list phát triển Python khi đó rằng vì sao một dự án “mã nguồn mở” lại dùng compiler độc quyền, và câu trả lời là MSVC là lựa chọn mang tính lịch sử, giờ không thể đổi được nữa. Lời giải thích là vì Microsoft cung cấp hạ tầng miễn phí cho Python Foundation để chạy CI và build, đồng thời cũng cung cấp các lập trình viên làm việc trên trình thông dịch Python. Nói cách khác, nhân viên Microsoft được Microsoft trả tiền để làm việc trên trình thông dịch Python, và được chỉ đạo không loại công cụ Microsoft khỏi toolchain
Mỗi năm tình hình lại tệ hơn. Như các dự án tương tự, thành công đã tạo mảnh đất để những người không có năng lực đáng kể nắm quyền, và Python Foundation cùng các dự án xung quanh như PyPA bắt đầu đầy những người leo lên vị trí không phải bằng cách đóng góp mã hữu ích, mà bằng cách viết các trang quy tắc ứng xử. Những cuộc đấu đá vô tận xoay quanh quy tắc ứng xử và kiểm soát vị trí này cuối cùng dẫn đến việc các contributor lâu năm rời đi hoặc bị đẩy ra, và gần đây còn có việc Tim, người tạo ra Tim sort, bị cấm
Microsoft tiếp tục thúc đẩy chương trình nghị sự quen thuộc của họ trong mọi dự án họ nhúng tay vào. Họ thêm cả đống tính năng vô dụng để quảng bá, làm dự án chao đảo theo đủ hướng, và đặc biệt là bắt nó bám theo trào lưu hết mức có thể. Vì thế Python, dù là ngôn ngữ có hệ thống kiểu hoàn toàn khác, vẫn cố thêm tối đa các kiểu theo phong cách machine learning; và dù là ngôn ngữ một nửa dùng để gắn động các thư viện native, vẫn ám ảnh với biên dịch trước và JIT. Về bản chất là biến nó thành C# không có ngoặc nhọn
Microsoft đủ khôn để biết rằng nếu công khai tuyên bố sở hữu Python thì nhiều người sẽ rời xa công nghệ này, nên họ không quảng bá rầm rộ. Nhưng họ vẫn tiếp tục khiến các nhà phát triển phụ thuộc vào công cụ của mình, và một ngày nào đó sẽ đến để thu hồi khoản đầu tư đó
Nhưng những gì họ đưa ra cho đến nay về cơ bản chỉ là hàng tỷ bài blog của contributor kiểu “hệ thống do chúng tôi tạo ra đang hạn chế chúng tôi không thể giúp ích, và dù sao thì đó cũng không phải lỗi của chúng tôi”
Họ có vẻ đã chìm quá sâu vào hệ thống nội bộ và chính trị nội bộ đến mức không còn biết vì sao mình ở đó nữa
Vì vậy nếu ai đó thực sự làm tốt và chiếm lĩnh thị trường như Astral, thì đó chính là kết quả mà chúng ta, với tư cách cộng đồng, xứng đáng nhận
[1]: Ở đây tôi đang nói về chính trị nội bộ. Không phải kiểu náo loạn cực hữu kỳ quặc “tuyển dụng DEI!”
Các công cụ này vẫn còn vấn đề về thẩm quyền
Khác với cargo ở chỗ chúng không được PyPA phê chuẩn. Đồng thời, PyPA trong nhiều năm đã không đưa ra được giải pháp toàn diện, còn các công cụ đóng gói và phát triển Python thì cứ tăng lên. Chỉ mới 3–4 năm trước, poetry và pipenv còn có vẻ như đang giải quyết các vấn đề đóng gói Python mà pip+virtualenv không giải quyết được
Giờ tôi nghĩ PyPA nên lên con thuyền astral.sh, nhưng không biết họ có làm vậy nếu không có một mức kiểm soát nhất định hay không
Theo tôi, phần lớn là do quan hệ cá nhân, và khi đó Pipenv là một thảm họa. Ý định thì tốt, nhưng ở công ty, ngay cả với repository có tương đối ít dependency phổ biến, chúng tôi vẫn phải chờ một tiếng để cập nhật lock file. Nó đơn giản là không hoạt động
Về mặt thực tế, tôi rất biết ơn các công việc kỹ thuật khó mà PyPA làm. Nhưng họ đang khuyến nghị bộ công cụ nào thì tôi không quan tâm lắm. Tôi nghĩ tốt hơn là dùng thứ cộng đồng đang dùng và đừng lo về đề xuất “chính thức”
Số người tham gia không rõ, và cũng không chắc PyPA liên quan đến Python lõi hay PSF ở mức nào
Tôi nghĩ sự phê chuẩn thực sự hữu ích phải đến từ chính dự án Python lõi. Trong một thế giới lý tưởng, tutorial Python chính thức sẽ bắt đầu bằng “đây là cách cài Python”, rồi hướng dẫn cài uv, giống như tài liệu Rust chính thức trỏ đến rustup và cargo
Tôi rất hy vọng PSF xây dựng được một quan hệ nào đó với Astral để một ngày nào đó hiện thực như vậy có thể xảy ra
Trong bối cảnh này, tôi nghĩ họ đã tự chứng minh rằng mình phần lớn không liên quan. Mọi thứ họ chạm vào dường như đều mục ruỗng, nên đáng tiếc là tôi mong họ đứng xa vấn đề này. Nói như vậy khiến tôi khó chịu và cũng trái với triết lý của tôi, nhưng đó chỉ là đánh giá phản ánh tình trạng hiện tại. Tôi đã làm việc full-time với Python trong 10 năm, và các hệ sinh thái đóng gói khác trên thực tế đã vượt Python hơn một vòng
Giờ tôi cũng không còn để tâm đến các sắc thái kiểu “đây là vấn đề thực thi của PyPA hay phạm vi vai trò được định ra đã sai”. Tôi cũng chán bị kéo vào những cuộc thảo luận như vậy rồi
Armin ủng hộ việc uv thống trị lĩnh vực này, nhưng cũng thừa nhận rằng vì dựa trên vốn đầu tư mạo hiểm nên có thể bị rug pull
Ông nói rằng giải pháp cho vấn đề tiềm ẩn đó là “rất dễ fork”, nhưng chẳng phải fork về bản chất sẽ tạo ra sự phân mảnh lớn hơn sao? Chính là vấn đề mà ông ấy muốn giải quyết
Nếu là một công cụ muốn thống trị cục diện đóng gói Python, tôi nghĩ nó nên do cộng đồng dẫn dắt và kiểm soát
Mức độ phân mảnh sau khi đã thống nhất một phần nhờ một công cụ bị rug pull có thể thấp hơn nhiều so với trước khi thống nhất
Và cộng đồng tưởng tượng đó còn cần thêm vài chục năm nữa để tạo ra một công cụ thống trị tuyệt vời sao?
Sáng nay ở công ty, do Poetry chậm, chúng tôi đã xem xét chuyển phần mềm của mình từ Poetry sang uv
Đến giờ chủ yếu là đọc rất nhiều tài liệu nhưng tiến triển thực tế chưa nhiều. Trước đây tôi cũng là người chuyển sang Poetry, và khi đó đơn giản hơn nhiều. Theo những gì tôi thấy đến giờ, Poetry đã cố tạo ra một trình quản lý gói đơn giản hoạt động giống các trình quản lý gói khác, còn uv dường như giữ lại khá nhiều sự điên rồ của các gói Python
Cũng không có chuyện một thay đổi nhỏ của Poetry làm hỏng định dạng package.toml, hay thời gian resolve trên nhiều index kéo dài hơn vì “sources” ngu ngốc không hoạt động với các phụ thuộc bắc cầu
uv thực sự có cảm giác như cắm thẳng vào luồng công cụ Python tiêu chuẩn
Tôi cũng không trách nếu mọi người bỏ qua lượt này và chờ phiên bản 2026 của “Trình quản lý gói Python: lần này chúng tôi đã thật sự giải quyết xong!”
Dù vậy tôi vẫn là một người dùng Nix hài lòng
Tôi rất thích cách đóng khung này
Nhờ công sức được nhiều người tích lũy dần trong thời gian dài, giờ đây chúng ta đã đến điểm mà chỉ vài người trong một công ty, với nỗ lực vừa phải, cũng có thể cải thiện tình hình một cách mạnh mẽ