Tính năng định dạng mã được đưa vào uv dưới dạng thử nghiệm

• Phiên bản uv mới cung cấp tính năng định dạng mã dưới dạng thử nghiệm
• Lệnh uv format sử dụng trình định dạng của Ruff ở bên trong để áp dụng kiểu định dạng nhất quán cho mã Python
• Giờ đây có thể dọn dẹp mã thuận tiện chỉ với uv mà không cần công cụ riêng biệt như trước
• Người dùng có thể tinh chỉnh chi tiết hành vi định dạng thông qua các đối số bổ sung
• Vì vẫn là tính năng thử nghiệm, cách dùng lệnh, xử lý lỗi và các phần khác vẫn có thể thay đổi

---

Tổng quan

Bản phát hành mới nhất của uv (0.8.13) đã giới thiệu uv format, một lệnh thử nghiệm mà các nhà phát triển Python đã chờ đợi từ lâu. Với tính năng này, có thể chuẩn hóa style mã chỉ bằng công cụ uv mà không cần quản lý thêm công cụ định dạng riêng trong dự án

uv format là gì?

• Lệnh uv format cung cấp khả năng định dạng mã Python thông qua giao diện uv
• Bên trong, nó gọi trình định dạng Ruff để tự động sắp xếp mã một cách nhất quán

Lưu ý cho nhà phát triển

Charlie Marsh (nhà phát triển uv) đã giải thích như sau trên Hacker News

Ruff và uv không được hợp nhất, và chúng vẫn là hai công cụ riêng biệt
Mục tiêu đơn giản là cải thiện trải nghiệm để người dùng có thể dùng trình định dạng mà không cần xem đó là một công cụ riêng
Điều này tương tự mối quan hệ giữa cargo fmt và rustfmt trong hệ sinh thái Rust

Cách sử dụng

• Cần dùng uv phiên bản 0.8.13 trở lên
• Chạy lệnh uv format ở thư mục gốc của dự án sẽ mang lại hiệu quả tương đương với việc chạy ruff format
• Cách thực thi tuân theo giao diện lệnh của uv

Truyền đối số bổ sung

• Có thể đặt các tùy chọn chi tiết để truyền cho Ruff theo dạng uv format -- [đối số bổ sung]
• Có thể tận dụng đồng thời sự tiện lợi của uv và khả năng cấu hình chi tiết của Ruff

Hướng dẫn về giai đoạn thử nghiệm

• Hiện tại, tính năng này vẫn ở giai đoạn thử nghiệm, nên trong tương lai cách dùng lệnh hoặc cách tích hợp với cấu trúc dự án có thể thay đổi
• Cách xử lý lỗi, định dạng đầu ra và các phần khác cũng sẽ tiếp tục được cải thiện
• Tính năng này dự kiến sẽ tiếp tục phát triển dựa trên phản hồi của người dùng

Kết luận

• Nếu bạn cần định dạng mã đơn giản và nhất quán cho dự án Python, có thể tích cực thử uv format
• Vì đây là bổ sung mang tính thử nghiệm, việc trực tiếp sử dụng rồi gửi phản hồi sẽ giúp đóng góp cho sự phát triển của uv trong tương lai

[GN⁺]

Ý kiến Hacker News

• Có vẻ sẽ tốt hơn nếu ruff được gộp với ty, còn uv thì nên tập trung vào quản lý gói hoặc dự án và không nên can thiệp cả vào việc chỉnh style code; theo tôi, trường hợp duy nhất mà uv nên sửa file mã nguồn là khi cập nhật dependency (PEP 723)
  • Tôi muốn làm rõ rằng ruff và uv không được hợp nhất với nhau mà sẽ tiếp tục là các công cụ riêng biệt; mục đích là mang lại trải nghiệm đơn giản hơn cho những người dùng không muốn phải bận tâm riêng đến formatter. Cách này tương tự như Rust Cargo, nơi cargo fmt bên dưới sẽ gọi rustfmt
  • Đây là kiểu mô phỏng cách Rust có cargo fmt
  • Về bản chất, mục tiêu là biến uv thành trình quản lý gói Python hoàn chỉnh, còn từng công cụ thành phần vẫn có thể dùng độc lập khi cần. Nói cách khác, uv là cargo cho Python; nếu chỉ cần type checker nhanh thì dùng ty, nếu chỉ cần formatter/linter thì dùng ruff, nên việc gộp ruff và ty lại với nhau có vẻ không mang nhiều ý nghĩa
  • Tôi cũng tò mò nếu một ngày nào đó ty được tích hợp vào uv thì sẽ ra sao. Vì tất cả đều đến từ astral.sh nên có thể đó chính là tầm nhìn, nhưng hiện tại ty vẫn chưa thực sự sẵn sàng
  • Bước tiếp theo hợp lý có lẽ là đưa vào tùy chọn như uv lint để bên dưới chạy ty; lý tưởng nhất là có một lệnh chuẩn hoặc một nhóm lệnh chuẩn để chuẩn bị dự án Python (format, lint, test, deploy). Có lẽ đây chính là tầm nhìn được nhắm tới ở đây
• Tôi thật sự rất thích dùng uv, nhưng cũng hơi lo vì nó đang ngày càng phình to không cần thiết. Ví dụ, nhiều subcommand hỗ trợ quá nhiều flag đặc thù, trong đó một số gần như cho ra cùng kết quả (uv run --no-project và uv run --active chẳng hạn). Tôi mong họ tập trung nhiều hơn vào việc cải thiện công cụ và tài liệu hiện có thay vì tiếp tục thêm tính năng mới không cần thiết
  • Biến một dự án Python trở nên ổn định, có thể tái tạo và có tính di động là việc cực kỳ khó. uv sync về mặt lý thuyết rất hữu ích vì chỉ build các tập package có thể tái tạo lại, nhưng các package phức tạp như torch-tensorrt hay flash-attn thì vẫn khó tránh khỏi việc phụ thuộc vào môi trường. Cộng đồng Python thường có xu hướng cá nhân hóa vấn đề theo kiểu "máy tôi chạy được", nhưng cái giá để phần mềm có thể triển khai, an toàn, lặp lại được và đáng tin cậy thì không bao giờ tự biến mất; rốt cuộc sẽ có ai đó phải trả cái giá đó về sau trong điều kiện còn hạn chế hơn. Cố gắng đáp ứng đủ mọi nhu cầu người dùng và yêu cầu vận hành đa dạng như vậy thực sự rất khó
  • Tôi không hiểu vì sao thêm subcommand vào uv lại bị xem là phình to. uv vốn đã là một công cụ phức tạp và tài liệu cũng khá đầy đủ rồi. Nếu các lệnh này trực quan và tự mô tả tốt thì việc thêm chúng là hoàn toàn tự nhiên
  • Khi nói về uv theo cách đó, tôi có cảm giác giống như đang nói rằng "lệnh make có quá nhiều target"
  • Tôi tò mò không biết các tùy chọn này được tích hợp vào file thực thi chính hay hoạt động như binary riêng giống apt hay cargo
• Tôi nghĩ bản cập nhật này rõ ràng là một quyết định tốt. Tôi không hiểu vì sao nhiều người lại phản đối một hướng đi tốt hơn như vậy. Đúng là "đã có thể làm được theo một cách bất tiện hơn một chút", nhưng vấn đề là nó vẫn "bất tiện hơn một chút"
  • Tôi không nghĩ việc uvx ruff format dài hơn một từ là điều tệ. Ngược lại, điều có thể gây rối hơn là formatter thực sự đang chạy là gì, liệu ruff có được cài tự động hay không, hay nó vẫn tải và cache công cụ như trước
  • Tôi rất đồng cảm với ý này, thậm chí sẽ còn tốt hơn nếu có thể cấu hình formatter ngay trong pyproject
  • Điều khiến tôi khó chịu nhất là hiện tại có vẻ chưa hỗ trợ các formatter khác; nếu dự án của tôi dùng black thì uv format sẽ không hoạt động
• Cá nhân tôi rất kỳ vọng thay đổi này sẽ giúp việc format code trong đội nhỏ của tôi (thành viên chủ yếu là actuary) trở nên dễ dàng hơn rất nhiều. uv cũng đã tạo ảnh hưởng khá lớn đến việc đưa Python vào sử dụng và onboarding, nên bất kỳ cách nào giúp nâng chất lượng code dễ hơn đều luôn đáng hoan nghênh. Tất nhiên vẫn có thể dùng riêng ruff hoặc cấu hình pre-commit, nhưng mô hình tư duy đơn giản kiểu uv <tính năng> rất có ích cho cả đội. Tôi cũng hy vọng có thể tích hợp với các formatter khác, và nếu còn hỗ trợ cả format cho model SQL/dbt thì gần như không còn gì để chê. Trước mắt tôi sẽ thử dùng để xem tiềm năng đến đâu
  • Nếu bạn thật sự cần format nhiều loại như vậy thì có lẽ dùng Makefile hoặc justfile sẽ hợp lý hơn; khi đó chỉ cần just format là có thể format Python/SQL/Bash/TypeScript cùng lúc
• Hơi có cảm giác thừa tính năng. Tôi đã dùng uv ngày càng nhiều trong hơn một năm qua và hiểu rõ những điểm mạnh của nó, nhưng đến giờ nó vẫn chưa phải lựa chọn số một của tôi, và thay đổi kiểu này cũng không khiến tôi thích nó hơn
  • Cụ thể thì bạn thấy cách làm này có vấn đề gì? Go, Rust và Elixir đều đang áp dụng kiểu này, và nó giúp việc thiết lập cũng như sử dụng dự án trong hệ sinh thái của các ngôn ngữ đó dễ dàng hơn rất nhiều. Nó còn có lợi ở chỗ cộng đồng có thể tập trung vào một bộ công cụ chung và mang lại điểm vào nhất quán cho cả người mới lẫn người nhiều kinh nghiệm
  • Nếu vậy thì tôi tò mò công cụ nào là lựa chọn ưu tiên nhất của bạn
• Có vẻ đến một lúc nào đó các chức năng của ruff sẽ được tích hợp vào uv và ty. Phần linting có thể do ty đảm nhiệm để thông minh hơn nhờ hiểu codebase sâu hơn, còn phần formatting thì giao cho uv vì mục tiêu chính của nó là quản lý dự án
  • ty đã nằm chung repository với ruff rồi, nên chuyện tích hợp có lẽ cũng không còn quá xa vời
• Trình quản lý gói là thứ thiết yếu để cài package cho môi trường vận hành, nhưng khi trộn nó với công cụ chỉ phục vụ phát triển thì tôi thấy nó giống một kiểu "cái bẫy hấp dẫn nhưng nguy hiểm". Dù Go và Rust cũng làm vậy, nếu nghĩ từ gốc thì đây có lẽ không hẳn là cấu trúc tốt
  • Nghe có thể hơi tiêu cực, nhưng với tư cách người đã dùng cargo rất nhiều, tôi chỉ mong có thêm nhiều "ý tưởng tệ" kiểu này hơn. Nếu uv thực sự trở thành cargo của Python thì trải nghiệm phát triển Python sẽ cải thiện cực mạnh. Với người đã dùng Python hơn 25 năm và từng phải tự mình vượt qua rất nhiều thiếu sót của hệ sinh thái, việc giờ đây hầu như chỉ cần uv là đủ mà không phải nghĩ ngợi nhiều khiến tôi rất hài lòng
• uv format mới về cơ bản chỉ là lối tắt của uv run --with ruff ruff
• Tôi thật sự thích hướng đi này; nếu theo ý tôi thì nên đặt tên là uv fmt, và có lẽ cũng nên đưa những thứ như uv vet vào roadmap
• Đã có quá nhiều công cụ format code được kiểm chứng rồi nên tôi hoàn toàn không thấy lý do phải thêm cái này. Nó chỉ tạo cảm giác tăng tính năng mà thôi, nên trước mắt tôi chưa định đưa nó vào bất kỳ pipeline nào
  • uv format gần như chỉ là frontend cho ruff format, chứ không phải thêm một formatter mới nào
  • Sẽ tốt nếu mọi người biết rằng đây chỉ là một lối tắt để dùng ruff format, vốn đã được rất nhiều người sử dụng dễ dàng hơn mà thôi