Rye และ uv: สิงหาคมคือฤดูเก็บเกี่ยวของ Python Packaging

ความคิดและบทความของ Armin Ronacher

Rye และ uv สำหรับ Python packaging: สิงหาคมคือฤดูแห่งการเก็บเกี่ยว

• เมื่อไม่กี่เดือนก่อน เขาได้ส่งมอบการดูแลเครื่องมือแพ็กเกจ Rye ให้กับ Astral
• ในช่วงหลายเดือนที่ผ่านมา ทีม Astral ได้พัฒนาเครื่องมือจำนวนมากสำหรับ Python packaging
• ในรีลีสล่าสุด uv ได้เพิ่มความสามารถอย่างการจัดการไฟล์ pyproject.toml, การรองรับ workspace, การอ้างอิงแพ็กเกจแบบโลคัล และการติดตั้งสคริปต์
• uv สามารถจัดการการติดตั้ง Python ได้ด้วย ทำให้มีความคล้ายกับ Rye มาก
• ผู้ที่ใช้งาน Rye ควรจับตาดู uv และส่งข้อเสนอแนะกลับไป

การบรรยายที่ EuroPython

• ไม่นานมานี้ เขาได้บรรยายที่ EuroPython ซึ่งจัดขึ้นที่กรุงปราก เกี่ยวกับมุมมองต่อ Python packaging และบทเรียนที่ได้จากการสร้าง Rye
• เป้าหมายของเครื่องมือ packaging คือการเป็นเครื่องมือที่ดีที่สุดที่ทุกคนใช้งาน
• Python กลายเป็นแพลตฟอร์มที่ได้รับความนิยมอย่างมากจากการลงทุนและความสนใจใน AI และ ML
• เขาอยากให้ผู้ที่เรียน Python จดจำประสบการณ์การพัฒนาที่ดีเยี่ยมได้
• ตอนนี้ยังมีความยากลำบากจากการมีเครื่องมือมากเกินไปและความไม่สอดคล้องกัน

การครองความเป็นใหญ่ของเครื่องมือ

• การครองความเป็นใหญ่หมายถึงการที่การลงทุนส่วนใหญ่ไหลเข้าสู่สแตกเดียว
• เครื่องมืออย่าง Rye ควรหายไปเมื่อมีการสร้างเครื่องมือหลักที่ครองตลาดได้แล้ว
• uv มีแนวโน้มสูงที่จะเป็นเครื่องมือนั้น
• ในท้ายที่สุด Rye จะถูกแทนที่ด้วย uv

พัฒนาการของระบบนิเวศ packaging

• เครื่องมือ packaging จำนวนมากถูกสร้างขึ้นบนพื้นฐานของพัฒนาการในระบบนิเวศ Python
• มีความก้าวหน้ามากมาย เช่น การเปลี่ยนจากไฟล์ setup.py ไปสู่ eggs และ wheels รวมถึงการนำมาตรฐานเมทาดาทามาใช้
• การพัฒนาของ Rust crates และไลบรารี Python ทำให้เครื่องมือเหล่านี้เกิดขึ้นได้

ก้าวต่อไปของชุมชน

• ชุมชนควรแนะนำเครื่องมือให้น้อยลง
• เคยมีช่วงเวลาที่มีการแนะนำ ez_setup.py และ easy_install
• ปัจจุบันมีการแนะนำ pip, pip-tools, poetry, PDM และอื่น ๆ
• ผู้ที่ดูแลโปรเจกต์ Python สำคัญ ๆ ควรลองใช้ uv และพิจารณาว่าควรแนะนำหรือไม่

เงินทุน VC ของ Astral

• ควรคิดให้รอบคอบว่าการที่ Astral ได้รับเงินทุน VC จะส่งผลต่ออนาคตอย่างไร
• เมื่อดูจากโค้ดและความสามารถของ uv แม้ในกรณีเลวร้ายที่สุด ชุมชนก็ยังจะอยู่ในจุดที่ดีกว่าก่อนที่ uv จะมีอยู่

สรุปของ GN⁺

• บทความนี้กล่าวถึงพัฒนาการของเครื่องมือ Python packaging และบทบาทของชุมชน
• uv มีความสามารถมากมาย และมีโอกาสสูงที่จะมาแทนที่ Rye
• ชุมชนควรแนะนำเครื่องมือให้น้อยลง และควรลองใช้ uv
• ควรพิจารณาผลกระทบที่เงินทุน VC ของ Astral อาจมีต่ออนาคต
• เครื่องมือที่มีความสามารถคล้ายกัน ได้แก่ pip, poetry และ PDM

[GN⁺]

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

• รีลีสล่าสุดของ uv ทำให้กระบวนการรีลีสของ Home Assistant เร็วขึ้นมาก

  • เวลารีลีสลดลงจากประมาณ 2.5 ชั่วโมงเหลือประมาณ 20 นาที
  • ดูรายละเอียดเพิ่มเติมได้จากบล็อกนักพัฒนาของ Home Assistant

• ตอนแรกคาดหวังว่าเครื่องมือใหม่จะมาแก้ปัญหา "packaging" ของ Python แต่จริง ๆ แล้วเป็นเรื่องการจัดการแพ็กเกจ

  • โดยส่วนตัวไม่เคยมีปัญหาใหญ่กับการจัดการแพ็กเกจของ Python
  • โดยทั่วไป pip ก็ทำงานได้ดี

• สิ่งที่น่าหงุดหงิดคือใน Python ไม่สามารถแพ็กแอปพลิเคชันให้เป็นไฟล์ executable ได้อย่างง่ายดาย

  • ใน production มักเห็นการ git clone และสร้าง virtualenv กันบ่อย
  • เรื่องนี้ไม่ค่อยดีในมุมมองด้านความปลอดภัย

• Python มีปัญหาเรื่อง packaging อยู่บ้าง แต่ก็ใช้งานกันมาได้ค่อนข้างดีด้วย pip พื้นฐาน

  • การเปลี่ยนจาก virtualenv เดิมไปใช้โมดูล venv ที่มีมาในตัวถือเป็นการเปลี่ยนแปลงครั้งใหญ่
  • ถ้าจะจัดการ dependency อย่างจริงจัง การสร้าง monorepo แบบ FAANG จะดีกว่า

• จากกรณี npm VC scam, การเข้าซื้อกิจการโดย Microsoft และสถานะ non-profit ทางกฎหมายของ OpenAI ทำให้ไม่อยากฝากโครงสร้างพื้นฐานหลักของภาษาไว้กับองค์กรแบบนี้

  • ผู้มีส่วนร่วมรายบุคคลนั้นยอดเยี่ยม แต่ปัญหาอยู่ที่แรงจูงใจทางการเงินในระดับองค์กร
  • เครื่องมืออย่าง lint ที่เร็ว, type check, code scan และ PR assistant เปลี่ยนเมื่อไรก็ได้ แต่ flow การติดตั้งกับ package repository ไม่ใช่แบบนั้น

• ปัญหาของเครื่องมือเหล่านี้คือเรื่องอำนาจรับรอง

  • มันต่างจาก cargo เพราะไม่ได้รับการรับรองจาก pypa
  • pypa เองก็ยังไม่สามารถนำเสนอโซลูชันแบบครอบคลุมได้
  • แค่เมื่อ 3-4 ปีก่อน poetry กับ pipenv ยังดูเหมือนจะแก้ปัญหานี้ได้
  • pypa ควรเข้าร่วมกับ astral.sh แต่ก็ไม่แน่ใจว่าจะทำได้โดยไม่ควบคุมหรือไม่

• Armin บอกว่า uv ควรเป็นตัวหลักในวงการนี้ แต่ก็ยอมรับว่าการมี VC สนับสนุนอาจก่อปัญหาได้

  • วิธีแก้ของเขาคือ uv สามารถ fork ได้ง่ายมาก
  • แต่การ fork ก็ทำให้เกิดความแตกแยกมากขึ้น

• ที่บริษัทกำลังพยายามย้ายซอฟต์แวร์ไปใช้ uv เพราะ poetry ช้าเกินไป

  • อ่านเอกสารไปเยอะ แต่สิ่งที่ทำได้จริงยังมีไม่มาก
  • ก่อนหน้านี้การย้ายไป poetry ง่ายกว่านี้มาก
  • uv ยังแบกปัญหาของแพ็กเกจ Python ไว้อีกหลายอย่าง

• ก็เข้าใจได้ถ้าหลายคนจะข้ามรอบนี้ไป แล้วรอ "ตัวจัดการแพ็กเกจ Python: คราวนี้แก้ได้จริงแล้ว!" ในปี 2026

  • ผู้ใช้ Nix ก็ยังคงพอใจเหมือนเดิม

• มีคนจำนวนหนึ่งที่หลงใหลในการพัฒนาตัวจัดการแพ็กเกจ

  • ถ้าสถานการณ์ยังเป็นแบบนี้ต่อไป ทุกปีก็คงจะมีตัวจัดการแพ็กเกจใหม่ออกมา