เพิ่มฟีเจอร์จัดรูปแบบโค้ดเข้าสู่ uv แบบทดลอง

• uv เวอร์ชันใหม่เพิ่มฟีเจอร์ จัดรูปแบบโค้ด แบบทดลอง
• คำสั่ง uv format ใช้ formatter ของ Ruff ภายในเพื่อจัดสไตล์โค้ด Python ให้สม่ำเสมอ
• เดิมทีต้องใช้เครื่องมือแยกต่างหาก แต่ตอนนี้สามารถ จัดระเบียบโค้ดได้ง่าย ๆ ด้วย uv เพียงตัวเดียว
• ผู้ใช้สามารถส่งอาร์กิวเมนต์เพิ่มเติมเพื่อ ปรับพฤติกรรมการจัดรูปแบบได้อย่างละเอียด
• เนื่องจากยังเป็น ฟีเจอร์ทดลอง จึงอาจมีการเปลี่ยนแปลงในวิธีใช้คำสั่ง การจัดการข้อผิดพลาด และส่วนอื่น ๆ

---

ภาพรวม

รีลีสล่าสุดของ uv (0.8.13) ได้นำฟีเจอร์ uv format ซึ่งเป็นคำสั่งแบบทดลองที่นักพัฒนา Python รอคอยมานานเข้ามาใช้ ด้วยฟีเจอร์นี้ จึงสามารถ จัดการสไตล์โค้ดได้ด้วย uv เพียงตัวเดียว โดยไม่ต้องดูแลเครื่องมือจัดรูปแบบแยกต่างหากภายในโปรเจกต์

uv format คืออะไร?

• คำสั่ง uv format มอบความสามารถในการ จัดรูปแบบโค้ด Python ผ่านอินเทอร์เฟซของ uv
• ภายในจะเรียกใช้ Ruff formatter เพื่อจัดโค้ดให้เป็นระเบียบและสม่ำเสมอโดยอัตโนมัติ

ข้อสังเกตสำหรับนักพัฒนา

Charlie Marsh (นักพัฒนา uv) อธิบายไว้บน Hacker News ดังนี้

Ruff และ uv ไม่ได้ถูกรวมเข้าด้วยกัน และยังคงเป็นเครื่องมือแยกกันอยู่
จุดประสงค์เป็นเพียงการปรับปรุงประสบการณ์ใช้งาน เพื่อให้ผู้ใช้สามารถใช้ formatter ได้โดยไม่ต้องมองว่าเป็นเครื่องมืออีกตัวหนึ่งแยกต่างหาก
มีความคล้ายกับความสัมพันธ์ระหว่าง cargo fmt และ rustfmt ใน ecosystem ของ Rust

วิธีใช้งาน

• ต้องใช้ uv เวอร์ชัน 0.8.13 ขึ้นไป
• หากรันคำสั่ง uv format ที่รากของโปรเจกต์ จะให้ผลเทียบเท่ากับการรัน ruff format
• วิธีการเรียกใช้งานเป็นไปตามอินเทอร์เฟซคำสั่งของ uv

การส่งอาร์กิวเมนต์เพิ่มเติม

• สามารถกำหนด ตัวเลือกแบบละเอียดที่จะส่งต่อให้ Ruff ได้ในรูปแบบ uv format -- [additional arguments]
• ทำให้ใช้งานทั้งความสะดวกของ uv และการตั้งค่าละเอียดของ Ruff ได้พร้อมกัน

คำแนะนำเกี่ยวกับช่วงทดลอง

• ฟีเจอร์นี้ยังอยู่ใน ขั้นทดลอง และในอนาคตวิธีใช้คำสั่งหรือแนวทางการผสานเข้ากับโครงสร้างโปรเจกต์อาจเปลี่ยนแปลงได้
• การจัดการข้อผิดพลาด รูปแบบเอาต์พุต และส่วนอื่น ๆ ก็มีแผนจะปรับปรุงต่อเนื่อง
• ฟีเจอร์นี้จะพัฒนาต่อไปโดยอิงจากข้อเสนอแนะของผู้ใช้

สรุปส่งท้าย

• หากโปรเจกต์ Python ของคุณต้องการ การจัดสไตล์โค้ดที่ง่ายและสม่ำเสมอ ก็สามารถลองใช้ uv format ได้อย่างจริงจัง
• เนื่องจากเป็น การนำมาใช้แบบทดลอง หากได้ลองใช้งานแล้วส่งข้อเสนอแนะกลับไป ก็จะช่วยสนับสนุนการพัฒนาของ uv ในอนาคตได้

[GN⁺]

ความคิดเห็นจาก Hacker News

• น่าจะดีกว่าถ้า ruff ไปรวมกับ ty ส่วน uv ก็ควรโฟกัสที่การจัดการแพ็กเกจหรือโปรเจกต์ และไม่ควรเข้ามาเกี่ยวกับการจัดรูปแบบโค้ด มองว่ากรณีเดียวที่ uv ควรแก้ไขไฟล์โค้ดคือเวลาที่อัปเดต dependency (PEP 723)
  • อยากย้ำให้ชัดว่า ruff กับ uv ไม่ได้ถูกรวมเป็นตัวเดียวกัน และจะยังคงเป็นเครื่องมือแยกกันต่อไป จุดประสงค์คือเพื่อมอบประสบการณ์ที่เรียบง่ายขึ้นให้ผู้ใช้ที่ไม่อยากต้องมาดูแล formatter เอง คล้ายกับใน Rust ที่ cargo fmt เรียก rustfmt ภายใน
  • มันก็แค่เลียนแบบแนวทางที่ Rust มี cargo fmt
  • โดยพื้นฐานแล้วเป้าหมายคือทำให้ uv เป็นตัวจัดการแพ็กเกจ Python แบบครบวงจร และเครื่องมือย่อยแต่ละตัวก็ยังสามารถใช้งานแยกเดี่ยวได้ถ้าต้องการ กล่าวคือ uv คือ cargo สำหรับ Python และถ้าต้องการแค่ type checker ที่เร็วก็ใช้แค่ ty ถ้าต้องการแค่ formatter/linter ก็ใช้แค่ ruff ได้ ดังนั้นการเอา ruff กับ ty มารวมกันจึงดูไม่ค่อยมีความหมายเท่าไร
  • ก็สงสัยเหมือนกันว่าถ้าวันหนึ่ง ty ถูกรวมเข้า uv ด้วยจะเป็นอย่างไร ทั้งหมดออกมาจาก astral.sh เหมือนกัน เลยอาจเป็นวิสัยทัศน์ของทีมก็ได้ แต่ตอนนี้ ty ยังไม่พร้อมนัก
  • ขั้นต่อไปที่ดูสมเหตุสมผลคือเพิ่มอะไรอย่าง uv lint แล้วให้มันเรียก ty ภายใน ในอุดมคติแล้วน่าจะดีถ้ามีคำสั่งมาตรฐานหนึ่งเดียวหรือชุดคำสั่งที่ใช้เตรียมโปรเจกต์ Python ได้ครบทั้ง format, lint, test, deploy บางทีนี่อาจเป็นวิสัยทัศน์ที่กำลังมุ่งไปก็ได้
• ชอบใช้ uv มากจริง ๆ แต่ก็แอบกังวลว่ามันจะค่อย ๆ บวมเกินจำเป็น เช่น หลาย subcommand รองรับแฟลกเฉพาะทางจำนวนมากเกินไป และบางอันก็ให้ผลแทบเหมือนกัน (uv run --no-project กับ uv run --active เป็นต้น) เลยอยากให้โฟกัสกับการปรับปรุงเครื่องมือเดิมและเอกสารมากกว่าการเพิ่มฟีเจอร์ใหม่ที่ไม่จำเป็น
  • การทำให้โปรเจกต์ Python มีความเสถียร ทำซ้ำได้ และพกพาได้ เป็นงานที่ยากมาก uv sync มีประโยชน์มากเพราะในทางทฤษฎีมันสร้างชุดแพ็กเกจที่ทำซ้ำได้อีกครั้ง แต่แพ็กเกจซับซ้อนอย่าง torch-tensorrt หรือ flash-attn ก็ยังขึ้นอยู่กับสภาพแวดล้อมอยู่ดี ชุมชน Python มักมีแนวโน้มจะทำให้ปัญหากลายเป็นเรื่องเฉพาะบุคคลแบบ “มันใช้ได้บนเครื่องฉัน” แต่ต้นทุนของการทำให้ซอฟต์แวร์ deploy ได้ ปลอดภัย ทำซ้ำได้ และเชื่อถือได้ ไม่เคยหายไปไหน สุดท้ายก็จะมีใครสักคนต้องจ่ายต้นทุนนั้นในภายหลังภายใต้ข้อจำกัดที่มากกว่า การพยายามตอบโจทย์ผู้ใช้และข้อกำหนดด้านปฏิบัติการที่หลากหลายเหล่านี้จึงเป็นเรื่องยากมากจริง ๆ
  • ไม่ค่อยเข้าใจว่าทำไมการเพิ่ม subcommand ให้ uv ถึงถูกมองว่าเป็นความบวม ทั้งที่ uv ก็เป็นเครื่องมือที่ซับซ้อนอยู่แล้วและมีเอกสารค่อนข้างดี ถ้าคำสั่งมันตรงไปตรงมาและอธิบายตัวเองได้แบบนี้ ก็น่าจะเพิ่มเข้ามาได้อย่างเป็นธรรมชาติ
  • เวลาพูดถึง uv มันให้ความรู้สึกคล้ายกับการบอกว่า “คำสั่ง make มี target มากเกินไป”
  • สงสัยว่าออปชันพวกนี้ถูกรวมอยู่ใน executable หลักเลยหรือเปล่า หรือทำงานเป็นไบนารีแยกเหมือน apt หรือ cargo
• คิดว่าการอัปเดตนี้เป็นทางเลือกที่ดีอย่างชัดเจน ไม่ค่อยเข้าใจว่าทำไมหลายคนถึงต่อต้านสิ่งที่ดีกว่า แน่นอนว่า “เราทำแบบนี้ได้อยู่แล้วด้วยวิธีที่ลำบากกว่าเล็กน้อย” นั้นจริง แต่มันก็ “ลำบากกว่าเล็กน้อย” อยู่ดี
  • ไม่คิดว่า uvx ruff format ที่ยาวกว่าอยู่หนึ่งคำจะเป็นปัญหา อันที่จริงสิ่งที่อาจทำให้สับสนมากกว่าคือไม่ชัดเจนว่า formatter ตัวไหนถูกเรียกใช้งาน, ruff ถูกติดตั้งอัตโนมัติหรือไม่ หรือมันจะดาวน์โหลดและแคชเครื่องมือไว้เหมือนเดิม
  • เห็นด้วยมาก ๆ และจะยิ่งดีขึ้นไปอีกถ้าสามารถตั้งค่า formatter จาก pyproject ได้
  • ข้อไม่พอใจใหญ่สุดคือดูเหมือนตอนนี้ยังไม่รองรับ formatter อื่น ถ้าโปรเจกต์ของฉันใช้ black ก็จะใช้ uv format ไม่ได้
• ส่วนตัวตื่นเต้นกับการเปลี่ยนแปลงนี้มาก เพราะน่าจะทำให้การจัดรูปแบบโค้ดของทีมเล็ก ๆ ของฉัน (ที่สมาชิกหลักเป็นนักคณิตศาสตร์ประกันภัย) ง่ายขึ้นแบบก้าวกระโดด และ uv ก็มีผลอย่างมากต่อการนำ Python เข้ามาใช้และการ onboarding ด้วย ดังนั้นวิธีใดก็ตามที่ช่วยยกระดับคุณภาพโค้ดให้ทำได้ง่ายขึ้นก็ยินดีต้อนรับเสมอ แน่นอนว่าอาจใช้ ruff แยกต่างหากหรือเซ็ต pre-commit ก็ได้ แต่ mental model ที่เรียบง่ายแบบ uv <ฟีเจอร์> ช่วยทีมได้มาก อยากให้เชื่อมกับ formatter อื่นได้ด้วย และถ้ารองรับการ format โมเดล SQL/dbt ได้ด้วยก็คงไม่มีอะไรจะขอเพิ่มแล้ว เดี๋ยวคงลองใช้ดูก่อนเพื่อดูศักยภาพ
  • ถ้าต้องการ multi-formatting ระดับนั้น บางทีใช้ Makefile หรือ justfile อาจเหมาะกว่า เพราะจะทำ just format เพื่อ format ทั้ง Python/SQL/Bash/TypeScript พร้อมกันได้
• รู้สึกว่ามันเริ่มมีฟีเจอร์มากเกินไปนิดหน่อย ใช้ uv มากขึ้นเรื่อย ๆ มานานกว่าหนึ่งปีแล้วและก็เห็นข้อดีของมัน แต่จนถึงตอนนี้มันก็ยังไม่ใช่ตัวเลือกอันดับหนึ่งของฉัน และการเปลี่ยนแปลงแบบนี้ก็คงไม่ได้ทำให้ชอบมันมากขึ้น
  • อยากรู้จริง ๆ ว่าวิธีนี้มีปัญหาตรงไหน เพราะ Go, Rust และ Elixir ก็ใช้แนวทางนี้กันทั้งหมด และมันช่วยให้การตั้งค่าและใช้งานโปรเจกต์ใน ecosystem ของภาษานั้นง่ายขึ้นมาก มีข้อดีตรงที่ชุมชนโฟกัสกับชุดเครื่องมือร่วมกัน และมีจุดเริ่มต้นที่สม่ำเสมอทั้งสำหรับมือใหม่และผู้เชี่ยวชาญ
  • ถ้าอย่างนั้นอยากรู้ว่าคุณชอบเครื่องมือตัวไหนมากที่สุด
• คิดว่าสักวันหนึ่งความสามารถของ ruff น่าจะถูกรวมเข้ากับ uv และ ty โดยเรื่อง linting อาจให้ ty ที่เข้าใจ codebase ได้ดีกว่ารับผิดชอบเพื่อให้ฉลาดขึ้น ส่วน formatting ก็เหมาะจะให้ uv ที่มีจุดประสงค์หลักด้านการจัดการโปรเจกต์เป็นคนดูแล
  • ty ก็อยู่ใน repository เดียวกับ ruff อยู่แล้ว ดังนั้นการรวมกันก็ดูไม่ใช่เรื่องไกลตัวนัก
• ตัวจัดการแพ็กเกจเป็นสิ่งจำเป็นสำหรับการติดตั้งแพ็กเกจในสภาพแวดล้อมใช้งานจริง แต่พอเอามาปะปนกับเครื่องมือสำหรับงานพัฒนาโดยเฉพาะ มันให้ความรู้สึกเหมือน “กับดักที่น่าดึงดูดแต่ก็อันตราย” แบบหนึ่ง ถึง Go และ Rust จะทำแบบนั้นเหมือนกัน แต่ถ้าคิดในเชิงพื้นฐานแล้วก็ไม่แน่ใจว่ามันเป็นโครงสร้างที่ดีนัก
  • อาจฟังดูแรงมาก แต่ในฐานะคนที่ใช้ cargo มาเยอะ ก็อยากให้มี “ไอเดียที่ไม่ดี” แบบนี้เพิ่มขึ้นอีก ถ้า uv กลายเป็น cargo ของ Python ได้จริง ประสบการณ์การพัฒนา Python จะดีขึ้นมาก ตลอดเวลากว่า 25 ปีที่ใช้ Python มา ฉันต้องฝ่าข้อจำกัดหลายอย่างมาตลอด และตอนนี้การที่ทำแทบทุกอย่างได้ด้วย uv ตัวเดียวโดยไม่ต้องคิดมากนั้นน่าพอใจมาก
• uv format ใหม่นั้นจริง ๆ แล้วแทบจะเป็นชอร์ตคัตของ uv run --with ruff ruff
• ชอบทิศทางนี้มาก ถ้าเป็นไปตามใจฉันจะตั้งชื่อมันว่า uv fmt และอาจเพิ่มอะไรอย่าง uv vet เข้าไปในโรดแมปด้วย
• มีเครื่องมือจัดรูปแบบโค้ดที่พิสูจน์ตัวเองมาแล้วมากมายอยู่แล้ว เลยไม่รู้สึกเลยว่ามีเหตุผลอะไรที่ต้องเพิ่มสิ่งนี้เข้ามา มันให้ความรู้สึกเหมือนมีแต่ฟีเจอร์เพิ่มขึ้น ดังนั้นคงยังไม่เอาไปใส่ใน pipeline ไหนไปอีกพักหนึ่ง
  • uv format ก็แทบจะเป็น frontend ของ ruff format เท่านั้น ไม่ได้มี formatter ใหม่เพิ่มขึ้นมา
  • อยากให้รับรู้ว่ามันเป็นแค่ชอร์ตคัตที่ทำให้ใช้งาน ruff format ซึ่งคนจำนวนมากใช้อยู่แล้วได้สะดวกขึ้นเท่านั้น