Fitur pemformatan kode diperkenalkan secara eksperimental ke uv

 (pydevtools.com)
1 poin oleh GN⁺ 2025-08-23 | 1 komentar | Bagikan ke WhatsApp
  • Pada versi baru uv, fitur pemformatan kode disediakan secara eksperimental
  • Perintah uv format secara internal menggunakan formatter milik Ruff untuk menata gaya kode Python secara konsisten
  • Kini pekerjaan merapikan kode dapat dilakukan dengan mudah hanya dengan uv tanpa alat terpisah
  • Pengguna dapat menyesuaikan perilaku pemformatan secara rinci melalui argumen tambahan
  • Karena masih merupakan fitur eksperimental, masih ada kemungkinan perubahan pada cara perintah, penanganan error, dan lainnya

Ikhtisar

Rilis terbaru uv (0.8.13) memperkenalkan fitur uv format, sebuah perintah eksperimental yang telah lama dinantikan oleh pengembang Python. Dengan fitur ini, penataan gaya kode dapat dilakukan hanya dengan alat uv tanpa perlu mengelola alat pemformatan tambahan di dalam proyek

Apa itu uv format?

  • Perintah uv format menyediakan pemformatan kode Python melalui antarmuka uv
  • Secara internal, perintah ini memanggil formatter Ruff untuk merapikan kode secara otomatis dan konsisten

Catatan untuk pengembang

Charlie Marsh (pengembang uv) menjelaskan hal berikut di Hacker News

Ruff dan uv tidak digabungkan, dan tetap merupakan alat yang terpisah.
Tujuannya semata-mata untuk meningkatkan pengalaman agar pengguna dapat memanfaatkan formatter tanpa harus menganggapnya sebagai alat terpisah.
Hubungannya mirip dengan cargo fmt dan rustfmt di ekosistem Rust.

Cara penggunaan

  • Harus menggunakan uv versi 0.8.13 atau lebih baru
  • Menjalankan perintah uv format di root proyek akan memberikan efek yang sama dengan menjalankan ruff format
  • Cara eksekusinya mengikuti antarmuka perintah uv

Meneruskan argumen tambahan

  • Dengan bentuk uv format -- [argumen tambahan], Anda dapat menetapkan opsi detail yang diteruskan ke Ruff
  • Anda dapat memanfaatkan kemudahan uv sekaligus pengaturan rinci dari Ruff

Panduan tahap eksperimental

  • Saat ini fitur tersebut masih berada pada tahap eksperimental, dan ke depannya cara perintah atau metode integrasi dengan struktur proyek dapat berubah
  • Penanganan error, format output, dan hal lainnya juga akan terus ditingkatkan
  • Fitur ini akan berkembang dengan mencerminkan umpan balik pengguna

Penutup

  • Jika Anda memerlukan penataan gaya kode yang mudah dan konsisten untuk proyek Python, uv format layak untuk dicoba secara aktif
  • Karena ini adalah penerapan eksperimental, mencoba langsung lalu memberikan umpan balik dapat membantu perkembangan uv ke depannya

Bacaan terkait

1 komentar

 
GN⁺ 2025-08-23
Komentar Hacker News
  • Akan lebih baik kalau ruff digabung dengan ty; uv sebaiknya fokus pada manajemen paket atau proyek, dan menurut saya tidak perlu ikut campur sampai ke pengaturan gaya kode. Satu-satunya kasus di mana uv boleh memodifikasi file kode mestinya hanya saat pembaruan dependensi (PEP 723)
    • Saya ingin menegaskan bahwa ruff dan uv tidak digabung dan akan tetap menjadi alat terpisah. Tujuannya adalah memberi pengalaman yang lebih sederhana bagi pengguna yang tidak ingin repot memikirkan formatter terpisah. Konfigurasinya mirip seperti cargo fmt di Rust yang secara internal menjalankan rustfmt
    • Ini meniru cara Rust cargo menyediakan cargo fmt
    • Pada dasarnya, tujuannya adalah menjadikan uv sebagai package manager Python yang lengkap, sementara tiap alat komponennya tetap bisa dipakai secara terpisah bila diperlukan. Jadi uv adalah semacam cargo untuk Python; kalau hanya butuh type checker cepat pakai ty saja, kalau hanya butuh formatter/linter pakai ruff saja. Dalam konteks itu, menggabungkan ruff dan ty tampaknya tidak terlalu masuk akal
    • Saya juga penasaran bagaimana jadinya jika suatu hari ty juga digabung ke uv; semuanya berasal dari astral.sh jadi mungkin memang itu visinya, tetapi ty sendiri masih belum cukup matang
    • Langkah berikutnya yang terasa logis adalah menambahkan opsi seperti uv lint yang secara internal menjalankan ty. Idealnya, akan bagus jika menyiapkan proyek Python—format, lint, test, deploy—bisa dilakukan lewat satu perintah standar atau serangkaian command yang konsisten. Mungkin memang itulah visi di balik ini
  • Saya benar-benar suka memakai uv, tetapi agak khawatir karena terasa makin membengkak tanpa perlu. Misalnya, banyak subcommand mendukung flag unik dalam jumlah sangat banyak, dan beberapa hampir menghasilkan hal yang sama juga (uv run --no-project dan uv run --active, misalnya). Daripada terus menambah fitur baru yang kurang perlu, saya berharap mereka lebih fokus memperbaiki tool yang ada dan dokumentasinya
    • Membuat proyek Python stabil, reproducible, dan portable itu pekerjaan yang benar-benar sulit. uv sync sangat berguna karena secara teori hanya membangun set paket yang bisa direproduksi ulang, tetapi paket rumit seperti torch-tensorrt atau flash-attn tetap tak bisa lepas dari perbedaan lingkungan. Komunitas Python sering cenderung mempersonalisasi masalah dengan sikap seperti "berjalan di komputer saya", tetapi biaya untuk membuat perangkat lunak bisa didistribusikan, aman, repeatable, dan andal tidak pernah benar-benar hilang; pada akhirnya seseorang akan membayar biaya itu nanti dalam situasi yang lebih terbatas. Memenuhi beragam pengguna dan kebutuhan operasional seperti ini memang sangat sulit
    • Saya kurang paham kenapa menambahkan subcommand ke uv dianggap sebagai pembengkakan. uv memang sudah alat yang kompleks, tetapi juga terdokumentasi dengan baik. Jika perintahnya seintuitif dan sejelas ini, menurut saya penambahannya cukup alami
    • Saat membicarakan uv, rasanya seperti mengatakan "perintah make punya terlalu banyak target"
    • Saya penasaran apakah opsi-opsi ini dibangun langsung ke executable utama, atau berjalan sebagai binary terpisah seperti apt atau cargo
  • Menurut saya pembaruan ini jelas keputusan yang bagus. Saya tidak begitu paham kenapa banyak orang menolak arah yang lebih baik. Memang benar bahwa "ini sudah bisa dilakukan dengan cara yang sedikit lebih merepotkan", tetapi intinya tetap: itu "sedikit lebih merepotkan"
    • Saya rasa uvx ruff format yang lebih panjang satu kata bukanlah masalah besar. Justru bisa lebih membingungkan apakah formatter yang dijalankan menjadi kurang jelas, apakah ruff dipasang otomatis, atau apakah tool-nya diunduh dan di-cache seperti sebelumnya
    • Sangat setuju soal itu; bahkan akan lebih baik lagi kalau formatter bisa dikonfigurasi dari pyproject
    • Keluhan terbesar saya saat ini adalah belum tampak ada dukungan untuk formatter lain. Kalau proyek saya memakai black, uv format jadi tidak berguna
  • Secara pribadi saya sangat antusias karena perubahan ini tampaknya akan membuat formatting kode jauh lebih mudah untuk tim kecil saya yang anggota utamanya aktuaria. Karena uv juga cukup besar dampaknya dalam adopsi Python dan onboarding, cara apa pun yang mempermudah peningkatan kualitas kode selalu saya sambut. Tentu saja kami bisa memakai ruff secara terpisah atau menyusun konfigurasi pre-commit, tetapi model mental sederhana uv <fitur> sangat membantu tim. Akan bagus juga kalau bisa terhubung dengan formatter lain, dan kalau sampai mendukung formatting model SQL/dbt, rasanya tidak ada lagi yang perlu diminta. Untuk sekarang saya ingin mencobanya dulu dan melihat potensinya
    • Kalau memang butuh formatting multi-bahasa sebanyak itu, mungkin lebih baik memakai Makefile atau justfile. Dengan begitu, just format bisa memformat Python/SQL/Bash/TypeScript sekaligus
  • Rasanya agak terlalu banyak fitur. Saya makin sering memakai uv selama lebih dari setahun dan paham kelebihannya, tetapi sampai sekarang itu belum jadi pilihan nomor satu saya, dan perubahan seperti ini sepertinya tidak akan membuat saya lebih menyukainya
    • Saya penasaran, tepatnya apa yang bermasalah dari pendekatan ini? Go, Rust, dan Elixir semua memakai cara seperti ini, dan itu sangat memudahkan setup serta penggunaan proyek di ekosistem bahasa tersebut. Ada keuntungan karena komunitas bisa berfokus pada toolset bersama dan memberi titik masuk yang konsisten baik untuk pemula maupun pengguna ahli
    • Kalau begitu, saya penasaran tool mana yang paling Anda sukai
  • Sepertinya suatu hari nanti fitur-fitur ruff akan terintegrasi ke uv dan ty. Linting bisa menjadi lebih pintar jika ditangani ty yang lebih memahami codebase, sedangkan formatting cocok ditangani uv yang fokus utamanya adalah manajemen proyek
    • ty sudah berada di repository yang sama dengan ruff, jadi integrasi itu rasanya bukan hal yang terlalu jauh
  • Package manager memang penting untuk memasang paket di lingkungan operasional, tetapi mencampurnya dengan tool khusus development terasa seperti semacam 'jebakan yang menarik tapi berbahaya'. Memang Go dan Rust juga melakukan itu, tetapi kalau dipikir-pikir secara mendasar, saya rasa itu bukan struktur yang terlalu baik
    • Ini mungkin terdengar sangat buruk, tetapi sebagai orang yang banyak memakai cargo, saya justru berharap lebih banyak "ide buruk" seperti ini. Jika uv benar-benar menjadi cargo untuk Python, pengalaman pengembangan Python akan meningkat drastis. Setelah lebih dari 25 tahun memakai Python dan terus berusaha menutupi banyak kekurangannya, sekarang bisa melakukan semuanya dengan uv tanpa banyak berpikir terasa sangat memuaskan
  • uv format yang baru pada dasarnya hanyalah singkatan untuk uv run --with ruff ruff
  • Saya sangat suka arah ini. Kalau sesuai keinginan saya, namanya akan dibuat uv fmt, dan mungkin uv vet juga bagus dimasukkan ke roadmap
  • Sudah ada banyak tool code formatter yang terbukti, jadi saya sama sekali tidak merasa ada alasan kuat untuk menambahkan ini. Rasanya cuma menambah fitur, jadi untuk sementara saya tidak berniat memasukkannya ke pipeline mana pun
    • uv format pada dasarnya hanya frontend untuk ruff format, bukan menambahkan formatter baru
    • Saya rasa penting untuk memahami bahwa ini cuma shortcut agar ruff format, yang sudah dipakai banyak orang, bisa digunakan dengan lebih mudah