Rye: trải nghiệm Python không phiền toái

(rye.astral.sh)

2 điểm bởi GN⁺ 2024-07-10 | 2 bình luận | Chia sẻ qua WhatsApp

Rye là một công cụ quản lý dự án và gói từng nhằm xử lý việc cài đặt Python, dự án pyproject.toml, dependency, virtualenv và cài đặt công cụ toàn cục ở một nơi
Hiện tại việc phát triển đã dừng, và người dùng được khuyến nghị sử dụng dự án kế nhiệm uv do cùng các maintainer tạo ra
Người dùng hiện tại có thể tham khảo uv migration guide để chuyển đổi; Rye vẫn có thể tải về, nhưng không có kế hoạch cập nhật thêm
Việc dừng cập nhật cũng bao gồm cập nhật bảo mật, nên với dự án mới hoặc môi trường bảo trì dài hạn, nên cân nhắc chuyển sang uv
Trải nghiệm Python tích hợp mà Rye hướng tới bao trùm cả các dự án phức tạp và monorepo, nhưng trọng tâm bảo trì đã chuyển sang uv

Tình trạng hiện tại của Rye

Dừng phát triển và khuyến nghị dùng uv
- Tất cả người dùng được khuyến nghị sử dụng uv
- uv là dự án kế nhiệm do cùng các maintainer tạo ra
- uv đang được bảo trì tích cực và được sử dụng rộng rãi hơn Rye rất nhiều
- Người dùng Rye hiện tại có thể tham khảo uv migration guide
- Rye vẫn có thể tiếp tục sử dụng, nhưng không có kế hoạch cập nhật thêm
- Cũng không có kế hoạch cập nhật bảo mật

Các tính năng Rye từng cung cấp

Rye là giải pháp quản lý dự án và gói cho Python
Được tạo ra với mục tiêu trở thành công cụ tất cả-trong-một cho người dùng Python
Xử lý các công việc sau trong một trải nghiệm tích hợp duy nhất
- Quản lý cài đặt Python
- Quản lý dự án dựa trên pyproject.toml
- Quản lý dependency
- Quản lý virtualenv
- Cài đặt công cụ toàn cục
Được thiết kế để xử lý các dự án phức tạp và monorepo
Có thể xem video giới thiệu tại Watch an introduction

2 bình luận

lum7671 2024-07-11

Tôi thì cũng đã một thời gian, sau khi dùng thử cái này cái kia
Introduction - PDM
đang được tôi sử dụng.

Có lẽ tôi cũng nên thử dùng Rye.

GN⁺ 2024-07-10

Ý kiến trên Hacker News

Phần lớn công việc phát triển packaging cốt lõi hiện đang diễn ra trong uv, và Rye dùng uv ở bên trong, nên khi uv tốt hơn thì Rye cũng tốt hơn theo
Ví dụ, gần đây uv đã thêm phân giải phụ thuộc phổ quát, nhờ đó có thể tạo requirements.txt được khóa bằng một kết quả phân giải duy nhất hoạt động trên mọi nền tảng và hệ điều hành, chứ không chỉ hệ thống đang chạy hiện tại; Rye phiên bản mới nhất cũng hỗ trợ tính năng này
https://github.com/astral-sh/uv
Tôi đang phát triển Rye và uv, nên nếu có câu hỏi thì tôi có thể trả lời
- Tôi tò mò liệu phân giải phụ thuộc phổ quát của Rye/UV có hoạt động đúng với PyTorch không, hay cũng gặp vấn đề giống Poetry
  https://github.com/python-poetry/poetry/issues/6409
  https://news.ycombinator.com/item?id=39257501
- Tôi muốn biết có thể theo dõi công việc hay kế hoạch cho file khóa đa nền tảng ở đâu không
  Đây là một trong những lý do khiến nhóm của tôi còn do dự khi chuyển sang. Vì chúng tôi làm ML, lấy một dự án dựa trên PyTorch làm ví dụ: trạng thái mong muốn là đặt toàn bộ dependency trong pyproject.toml, rồi từ máy Mac AArch64 hoặc workstation Windows AMD64 có thể tạo các file khóa cho các cấu hình nền tảng sau: Mac dùng MPS PyTorch mặc định, Windows dùng CUDA PyTorch, AArch64 Linux dùng CPU PyTorch, AMD64 Linux dùng CPU PyTorch, AMD64 Linux dùng CUDA PyTorch
  Cảm ơn vì đã tạo Ruff; chúng tôi rất hài lòng với cả linting lẫn formatting
- Công việc tuyệt vời. Trước đây thỉnh thoảng tôi phải thiết lập môi trường làm việc cho dự án trên máy tính mới, và pyenv+venv+pip lúc nào cũng khổ sở; giờ tôi đã chuyển sang Rye
  Bây giờ chỉ cần cài Rye, kéo từ GitHub về, gõ rye sync là xong
- Nếu cùng phụ trách cả uv lẫn rye thì tôi tò mò vì sao lại duy trì cả hai cùng lúc. Để tránh sự rối rắm do phân mảnh và gánh nặng lựa chọn, có lẽ nên kết thúc rye ngay bây giờ thì hơn
- Nhiều công ty coi trọng các bản build có thể dự đoán được và hiệu năng tốt đang chuyển sang, và trong quá trình đó thường cần tạo SBOM để đưa vào các công cụ như guac
  https://guac.sh/
  https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
  Nhờ tính năng mới thêm gần đây cho phép bỏ ghim dependency, trong quá trình phát triển có thể khuyến khích duy trì tính tương thích, đồng thời tạo được requirements.txt chính xác và tường minh để tái lập; nhờ vậy các bước quản lý lỗ hổng và SBOM dễ hơn nhiều so với các công cụ như Poetry
  Vì lý do tương tự, chúng tôi đang dùng https://hatch.pypa.io/latest/why/, và tôi cũng thích việc nó phối hợp tốt với uv
Điều khiến tôi ngần ngại với Rye là nó khuyến nghị khá mạnh việc dùng bản build Python không chuẩn
Trang triết lý (https://rye.astral.sh/philosophy/) giải thích rằng các bản build CPython từ python.org hoàn toàn không phù hợp; tùy nền tảng mà chỉ có file cài đặt .msi hoặc chỉ có tarball; và nhiều bản phân phối Python phân kỳ mạnh, tạo đủ loại vấn đề cho các hệ sinh thái con. Vì vậy dự án này dùng các bản build độc lập của indygreg, và nói rằng họ hy vọng một ngày nào đó sẽ có các bản build Python được quản lý tốt, đáng tin cậy để thay thế tình trạng hỗn loạn hiện nay
Thông tin về các bản build indygreg đó nằm ở https://gregoryszorc.com/docs/python-build-standalone/main/, và cũng có thể chọn Python khác: https://rye.astral.sh/guide/toolchains/
Tuy nhiên, tôi hầu như chưa từng gặp những vấn đề mà họ nói đến. Bản build Python chính thức tải từ python.org vẫn chạy được, Python bình thường cài bằng trình quản lý gói của distro cũng chạy được, và Python đi kèm trong image container Docker chính thức cũng chạy được
Các bản build đặc biệt đó chắc cũng chạy tốt, nhưng tính không chuẩn khiến tôi do dự. Thậm chí còn có cả danh sách những điểm đặc thù trong hành vi; tôi không hiểu vì sao lại thêm đặc thù vào một thứ vốn không có vấn đề. Việc triết lý của Rye quá tích cực thúc đẩy dùng các bản build đó cũng làm nó kém hấp dẫn hơn so với các lựa chọn mặc định dùng Python đã có sẵn trong hệ điều hành
- Có lẽ họ đang nói đến tình huống như thế này: bạn làm ở một công ty dùng thứ như CentOS cũ, trình quản lý gói hệ thống không cung cấp gì mới hơn Python 3.6, còn binary chính thức từ python.org khi chạy thì in ra lỗi khó hiểu về phiên bản glibc
  Muốn build Python từ source thì cần các dependency hệ thống mới và mất nhiều thời gian, rồi cuối cùng lại gặp lỗi còn khó hiểu hơn về header file bị thiếu. Tìm lỗi đó thì ra một cờ ./configure để né vấn đề mà GCC upstream đã sửa từ năm 2017, và dù sao thì cuối cùng cũng thành công
  Nếu bạn chưa từng gặp 3 lỗi như vậy hay môi trường build manylinux, nghĩa là bạn đã tránh được nguyên một thế giới đau khổ. Việc script hóa cài đặt trên Windows hay phần “giới hạn các lệnh CPU khả dụng” trên trang đó cũng tương tự
- Trong build, packaging và phân phối Python có hai thái cực. Một bên là con đường hoàng đạo, bên kia là hành lang với một nghìn lưỡi dao. Nếu đề xuất Python di động không có ý nghĩa với bạn, thì tức là bạn đã may mắn và vẫn luôn đi trên con đường hoàng đạo
Thường xuyên tải mã nguồn Python về, biên dịch với các tối ưu hóa production tiêu chuẩn rồi cài vào /use/local/python${version}; kể từ khi Python 3.7 ra mắt năm 2018, quy trình này hoạt động rất nhất quán
Theo kinh nghiệm của tôi, các lệnh này ổn định và nhất quán đến mức có thể tự động hóa. Tôi tò mò điểm mà tác giả cho là vấn đề, hay lời phản đối căn bản là gì
- Câu “bản build CPython của python.org hoàn toàn không phù hợp” có lẽ có nghĩa là không có binary cho macOS/Windows đối với các bản phát hành bảo mật của những phiên bản Python cũ
  Ví dụ, không thể tải file cài đặt Python 3.10.14; file cài đặt Windows cuối cùng là Python 3.10.11, bản ngày 5 tháng 4 năm 2023
- Đồng ý. Nên hỗ trợ PSF; việc khăng khăng rằng có một “cách đúng” mới là một lập trường kỳ lạ
Tôi thích Rye. Nó làm đúng những gì đã tuyên bố, thực sự khiến toàn bộ quy trình venv/phiên bản Python/đóng gói trở nên dễ chịu, và với những ai đã quen với cách dùng Python chính thức như pyproject.toml thì gần như cảm thấy trong suốt
Hơn nữa, nó khiến Python có cảm giác giống Cargo, mà Cargo cũng là một công cụ dễ dùng
- Nếu giống tôi, bạn bỏ qua các công cụ kiểu Poetry và vẫn ở lại với pip-tools, thì uv mà Rye dùng bên trong có thể thay thế trực tiếp
  Cá nhân tôi cho rằng pip-tools có thiết kế tốt hơn Poetry hay Pipenv rất nhiều. Nó trực giao với cả pip lẫn virtualenv, và cả hai đều là những luồng đã tồn tại lâu trong Python. Rye có thể được xem là một ví dụ cho thấy cách tiếp cận tuân thủ tiêu chuẩn, được cải tiến lặp lại, đã chiến thắng
  Ngoài cải thiện tốc độ nhờ Rust, tôi thích việc nó đưa ra các mặc định hợp lý về nơi đặt môi trường ảo (.venv) và cách cài nhiều phiên bản Python. Nghe có vẻ nhỏ, nhưng sau khi wheel giải quyết vấn đề cài numpy, những mặc định hợp lý như vậy cùng pip-tools tích hợp sẵn về cơ bản là tất cả những gì còn thiếu. Theo nghĩa đó, tôi cũng tự hỏi sau khi có binary wheel thì lý do tồn tại của Anaconda là gì
- Tôi bắt đầu dùng Python vì nghe nói mọi thứ đều có một cách làm duy nhất, nhưng trải nghiệm cài đặt và quản lý môi trường thì là một mớ hỗn độn
  Rất vui khi thấy giờ đây nó cuối cùng cũng đang khá hơn
- Nếu nó “khiến Python có cảm giác như Cargo” thì tôi bị thuyết phục ngay. Tôi đang nghĩ đến việc thử pixi vì Poetry mất cả ngày mà vẫn không phân giải được phụ thuộc
  Có vẻ trình quản lý gói Python còn nhiều hơn cả ứng dụng chat của Google
- Tôi tò mò “thực sự khiến nó dễ chịu” nghĩa là gì. Khó tóm tắt quá chăng? Tôi không tìm thấy nhiều điểm trong Anaconda hay Poetry mà về mặt trải nghiệm người dùng có cảm giác như một lựa chọn đặc biệt
  Và về mặt tuyển chọn/kiểm soát, đề xuất rằng nên tin một tổ chức nhỏ hơn thay vì một tổ chức lớn và lâu đời hơn có vẻ khó thuyết phục. Nói cách khác, tôi tò mò chính xác thứ nó tuyên bố làm là gì. Những gì tôi đọc được chỉ khoảng “trình quản lý gói tốt thì tốt, nhanh và tốt”, nên nếu có trang so sánh hoặc triết lý thì sẽ hay hơn
Sự hoài nghi trên HN đôi khi khiến tôi ngạc nhiên
Tôi thích Rye. Sau khi dùng các trình quản lý gói của ngôn ngữ khác như Cargo hay Hex, tôi luôn tiếc là Python không có hệ thống tương tự, và Rye đã hoàn toàn giải tỏa cơn khát đó. Với tư cách người không muốn cài nhiều công cụ chỉ để quản lý venv, phiên bản Python và phụ thuộc dự án, việc một mình Rye xử lý tất cả thật sự rất tuyệt
- Không biết bạn đã thử conda chưa. So với conda thì Rye thế nào?
  Tôi vẫn chưa có cảm nhận về Rye, nhưng conda cũng có thể quản lý tốt venv, phiên bản Python và phụ thuộc dự án
- Đồng ý. Rye đang hoạt động tốt với tôi. Tôi muốn một Cargo cho Python, và cho đến nay, theo góc nhìn của tôi, Rye đã đạt được điều đó
Gặp một trình quản lý phụ thuộc Python mới giống như tình cờ phát hiện một framework JavaScript mới
- Triết lý của tôi đơn giản. Nếu cần là chương trình có thể phân phối thì cứ dùng Go; nếu không cần thứ gì như port thì dùng Docker; nếu đội IT hoặc ai đó đưa cho bạn một máy tính đã cài hệ điều hành và phiên bản Python mà cả tổ chức dùng, thì dùng venv là được
  Nếu phải xử lý port, phải phân phối chương trình, hoặc thư viện phụ thuộc vào C hay thành phần hệ điều hành, thì tốt hơn là nhận việc tư vấn mà sau khi được trả tiền không cần quản lý codebase hay chịu trách nhiệm nữa
- Đúng vậy. Docker đã giải quyết vấn đề phân phối và chạy chương trình Python từ khoảng 10 năm trước rồi
  Ngày nay còn có thể chạy CUDA và PyTorch trong Docker. Trong các thread kiểu này, khi ai đó nói “cứ dùng Docker là được”, câu trả lời thường thấy là “tôi không muốn học Docker”, nhưng ngay cả khi chưa có chút kinh nghiệm Docker nào, dựng một container Python cũng chỉ mất 10 phút
- Đúng. Nhưng khác với những thứ như Poetry, cái này thực sự tốt
- Thực sự nghiêm trọng. Ở góc độ người dùng, thật bực bội khi sau từng ấy năm vẫn chưa có chuẩn
pixi(https://pixi.sh/latest/) khá tốt. Nó có thể cố định phiên bản Python, cài gói từ conda và PyPI, và được viết bằng Rust
- Trông thú vị, nhưng tôi thấy khó nghiêm túc đầu tư vào thêm một hệ sinh thái nữa. Cách bảo tải bằng curl rồi pipe sang bash, sau đó eval đầu ra của lệnh tùy ý khiến tôi thấy ngại
- Cảm ơn vì liên kết. Tôi tò mò không biết nó có nhanh hơn conda không
- pixi rất tuyệt. Nếu bạn dùng conda, pixi có thể là một lựa chọn thay thế conda với môi trường gắn với Git/thư mục dự án, tương tự devbox/devenv/flox
  Bối cảnh hơi phức tạp. Công ty Anaconda có conda được viết bằng Python, còn hệ sinh thái mã nguồn mở conda-forge là một kênh conda có bot build CI. Sau đó, cũng dưới mái nhà conda-forge, mamba viết bằng C++ xuất hiện như một lựa chọn thay thế conda, và nó là một thay thế drop-in thực sự ở mức alias conda=mamba phải hoạt động. Hiện nay conda cũng dùng libmamba làm bộ phân giải để tăng tốc
  Sau đó tác giả mamba tách nó thành pixi, viết lại bằng Rust và thay đổi triết lý về vị trí môi trường cũng như cách kích hoạt, nhưng vẫn hoàn toàn tương thích với môi trường conda

conda luôn hỗ trợ cài đặt các gói PyPI thông qua pip trong những trường hợp như khi chúng không có trên kênh conda, còn pixi hỗ trợ các gói PyPI thông qua uv. Vì vậy pixi nhanh. Theo bài blog, còn có các tối ưu hóa khác khiến nó nhanh hơn mamba rất nhiều
Nếu dùng các gói không phải Python thuần túy thì hệ conda là phù hợp. Việc chọn trình quản lý gói (conda/mamba/pixi) chỉ là thứ yếu
Vấn đề của PyPI là thiếu vai trò gác cổng. Cộng thêm việc thiếu một cách chuẩn để đóng gói các gói không phải Python thuần túy, môi trường có thể bị rò rỉ; đặc biệt nếu chỉ phân phối mã nguồn rồi làm những việc kỳ lạ như bootstrap môi trường trong setup.py, thậm chí bao gồm cả compiler, thì sẽ trở nên không thể tái lập
Ở phía conda, kênh conda-forge thực hiện kiểm soát chất lượng khá tốt. Họ kiểm tra các ràng buộc, giấy phép, vấn đề thiếu file giấy phép trong bản phân phối PyPI, cách ly môi trường, v.v. Tất nhiên không hoàn hảo, vì maintainer có thể dùng bot chính thức tự động merge các thay đổi PyPI có ràng buộc phiên bản sai
Vấn đề mà hiện không công cụ nào giải quyết được chủ yếu xoay quanh PyPI. Bạn phải xử lý các gói không có trên conda, và việc phát hành gói trên thực tế gần như bị buộc phải phát hành lên PyPI trước
Ngay cả khi cài một gói chỉ có trên PyPI thông qua conda, một số dependency của nó vẫn có thể có trên conda. Theo tôi biết, không có trình quản lý gói nào dùng các gói conda để thỏa mãn dependency của gói PyPI. Bạn có thể thêm thủ công các gói conda để khớp dependency, nhưng có nguy cơ không được áp dụng đúng các ràng buộc phiên bản
Ngay cả khi viết một gói Python mã nguồn mở, dù cấu hình chỉ phụ thuộc vào kênh conda, phần lớn vẫn phải hoặc nên phát hành lên PyPI trước. Vì việc phát hành trên kênh conda-forge trên thực tế yêu cầu gói phải tồn tại trên PyPI. Vì vậy với những người như tôi, Rye vẫn có thể hữu ích và đáng để xem xét

Cũng đáng lưu ý là những người phía uv (https://astral.sh/blog/uv) đã tiếp quản vai trò dẫn dắt dự án của Armin này
Trang giới thiệu có viết: “Rye is still a very experimental tool, but this guide is here to help you get started.”
Tôi rất kỳ vọng vào dự án này, nhưng dự định sẽ chờ đến khi nó đạt mức trưởng thành hơn. Tôi thích mọi thứ khác mà đội Astral đã đưa ra nên kỳ vọng rất lớn
Chúng tôi đang dùng rye để phát triển thư viện openai-python, và trải nghiệm rất tốt
Rye trông có vẻ hay và tôi cũng đã dùng Poetry khá vui vẻ, nhưng tôi thực sự càng tôn trọng chất lượng công cụ mặc định của Go
Mỗi lần bắt đầu một dự án Python, tôi lại có cảm giác phải học lại trạng thái mới nhất của việc quản lý dependency/môi trường ảo