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

 (lucumr.pocoo.org)
2 คะแนน โดย GN⁺ 2024-08-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังสิทธิ์การดูแล Rye ถูกโอนไปยัง Astral ในเดือนกุมภาพันธ์ 2024 ตัว uv ซึ่งเป็น resolver และ installer แกนหลักก็ได้รับการปรับปรุงอย่างรวดเร็ว และกำลังก้าวขึ้นมาเป็นตัวเลือกสำหรับการรวมเครื่องมือ Python packaging
  • uv เวอร์ชันล่าสุดมีทั้งการจัดการ pyproject.toml, การรองรับ workspace, การอ้างอิงแพ็กเกจภายในเครื่อง, การติดตั้งสคริปต์ และการจัดการการติดตั้ง Python ซึ่งกำลังดูดซับขอบเขตงานที่ Rye เคยรับผิดชอบ
  • แม้ผู้ใช้ Python หน้าใหม่จะเพิ่มขึ้นจากการลงทุนใน AI และ ML แต่ตัวเลือกเครื่องมือ packaging ที่มีมากมายและความเข้ากันได้ที่ไม่ตรงกัน ทำให้ ประสบการณ์นักพัฒนา ยังขาดความสม่ำเสมอ
  • ระบบนิเวศ packaging จำเป็นต้องมี เครื่องมือที่ครองตลาด ที่ทุกคนใช้ เพื่อให้การลงทุนและเอกสารต่าง ๆ ไปรวมอยู่บนสแตกเดียว และ Rye มีแนวโน้มจะเป็นเส้นทางย้ายผ่านไปสู่การเปลี่ยนไปใช้ uv เป็นศูนย์กลาง
  • การลงทุนจาก VC ใน Astral เป็นความเสี่ยงที่ PSF และโครงการแกนหลักของ Python ต้องพิจารณา แต่ uv ก็ถูกมองว่าเป็นโค้ดที่ต่อให้เกิดกรณีเลวร้ายที่สุดก็ยังสามารถ fork และดูแลรักษาต่อได้

กระแสการรวมฟังก์ชันจาก Rye ไปสู่ uv

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

เหตุผลที่เครื่องมือ Python packaging ควรรวมศูนย์

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

ความเป็นไปได้ที่ uv จะกลายเป็นเครื่องมือหลัก

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

การปลดระวาง Rye และการเปลี่ยนแปลงแนวทางแนะนำโครงการ Python

  • Rye รุ่นสุดท้ายที่คาดหวังคือรุ่นที่จะปลดระวางฟังก์ชันเฉพาะของ Rye ย้ายผู้ใช้ไปยัง uv และทำงานในลักษณะที่แทบจะเป็น alias ของ uv เสียเป็นส่วนใหญ่
  • การปลดระวาง Rye เพียงตัวเดียวไม่เพียงพอ
    • ปัจจุบัน Python ยังมีการใช้วิธีจัดการแพ็กเกจหลายแบบ
    • ชุมชนควรแนะนำเครื่องมือให้น้อยลงกว่านี้
  • Rye และ uv ถูกสร้างขึ้นบนความก้าวหน้าที่ยาวนานของระบบนิเวศด้านล่าง
    • การเปลี่ยนผ่านจาก setup.py ไปสู่ eggs และต่อไปยัง wheels
    • การเปลี่ยนผ่านจากการไม่มีมาตรฐานเมทาดาทา ไปสู่การมีมาตรฐาน
    • การเปลี่ยนผ่านจากระบบ build แบบผูกติด ไปสู่ ระบบ build แบบแยกส่วน
    • งานที่ทำให้ Python binary สามารถนำไปแจกจ่ายซ้ำและดาวน์โหลดได้
    • ระบบนิเวศของ Rust crates และไลบรารี Python ที่เกี่ยวข้อง
  • ชุมชนจำเป็นต้องพร้อมที่จะบอกว่าในวันหนึ่งจะไม่แนะนำเครื่องมือบางตัวอีกต่อไป
    • ในอดีต เอกสารแนะนำสำหรับนักพัฒนาใหม่เคยแนะนำ ez_setup.py และ easy_install
    • ต่อมาเอกสารแนะนำได้ถอด ez_setup.py ออกและแทนที่ด้วย pip
    • บางโครงการเคยแนะนำ pip-tools, poetry, PDM
    • ปัจจุบันหลายโครงการถึงขั้นแสดงคำแนะนำการติดตั้งพร้อมกัน 5 แบบเพราะมีเครื่องมือหลากหลายเกินไป
  • ผู้ดูแลโครงการ Python สำคัญ ๆ ควรลองใช้ uv ด้วยตนเอง และประเมินว่าสามารถแนะนำ uv ให้ผู้ใช้ได้หรือไม่
  • บทความ สิ่งที่ uv ทำได้ในตอนนี้ ที่ Charlie จาก Astral เขียนไว้ แสดงให้เห็นความก้าวหน้าปัจจุบันของ uv

การลงทุน VC ของ Astral และความเสี่ยงต่อชุมชน

  • ประเด็นที่หลีกเลี่ยงไม่ได้คือ Astral ผู้สร้าง uv เป็นบริษัทที่ได้รับ เงินลงทุนจาก VC
  • ในมุมของชุมชน การที่ใครสักคนทุ่มเงินจำนวนมากลงมาอาจสร้างโจทย์ใหม่ขึ้นได้
  • PSF และโครงการแกนหลักของ Python จำเป็นต้องพิจารณาประเด็นนี้
  • เมื่อดูจากโค้ดและพฤติกรรมของ uv แล้ว มันดูเป็นสิ่งที่แม้ในอนาคตที่เลวร้ายที่สุดก็ยังสามารถ fork และดูแลรักษาต่อได้
  • ต่อให้ Astral ปิดกิจการ หรือทำสิ่งที่น่าสงสัยอย่างมากในด้านไลเซนส์ ชุมชนก็อาจยังอยู่ในจุดที่ดีกว่าก่อนที่ uv จะมีอยู่เสียอีก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-23
ความเห็นจาก Hacker News

  • รีลีสล่าสุดของ uv ก็ถูกพูดถึงไปเมื่อวานนี้เช่นกัน: https://news.ycombinator.com/item?id=41302475
    บทความที่ลิงก์ไว้คือมุมมองที่ ผู้เขียน Rye เขียนหลังจากเห็นรีลีสนั้น

  • สำหรับคนที่สนใจ uv การใช้ uv แทน pip ทำให้ กระบวนการรีลีสของ Home Assistant เร็วขึ้นมาก
    เวลาที่ใช้ในการรีลีสลดจากประมาณ 2.5 ชั่วโมงเหลือประมาณ 20 นาที รายละเอียดอยู่ที่ https://developers.home-assistant.io/blog/2024/04/03/build-i... อนึ่ง ผมเป็นเพียงผู้ใช้ HA เท่านั้น

    • สิ่งที่ไม่เข้าใจคือ pip ใช้เวลา เกิน 1 ชั่วโมง ในการสร้างอิมเมจ ทั้งที่ไม่ใช่ภาษาแบบคอมไพเลอร์ด้วยซ้ำ
      แม้ผมจะใช้ Python แบบเบา ๆ แต่ก็ไม่เข้าใจว่ามันทำอะไรถึงได้นานขนาดนั้น และรู้สึกว่าไม่สมเหตุสมผลเอามาก ๆ

  • รู้ว่า Python packaging มีปัญหา แต่โดยส่วนตัวแล้วจนถึงตอนนี้แค่ plain pip ก็พาผมมาได้ไกลพอสมควรแล้ว
    การเปลี่ยนแปลงที่ใหญ่ที่สุดคือเดิมใช้ virtualenv แล้วเปลี่ยนมาใช้โมดูล venv ที่มีในตัว ถ้าจะจัดการ dependency อย่างจริงจังจริง ๆ ก็คงทำ monorepo แบบ FAANG แล้วหลีกเลี่ยงความยุ่งยากเกี่ยวกับ package manager

    • อยากแนะนำอย่างยิ่งให้ลองทำ monorepo เองดู
      ผมกำลังดูแล monorepo ของ Python ใน production อยู่ และ การจัดการ dependency คือขุมนรก กำลังลองนำฟีเจอร์ใหม่ ๆ บางอย่างของ Poetry มาใช้ แต่สภาพ ecosystem รอบ ๆ monorepo ขนาดใหญ่นั้นแย่มาก
    • ปัญหานี้ต้องคิดให้ลึกกว่านี้
      เป้าหมายไม่ใช่ “สำหรับผมแค่นี้ก็พอ” แต่ต้องมี เครื่องมือมาตรฐานสำหรับ package และ virtual environment ที่ขยายได้ตั้งแต่องค์กรที่มีนักพัฒนา Python 2 คน ไปจนถึงระดับหลายร้อยหรือหลายพันคน ไม่อย่างนั้น ecosystem จะแตกเป็นเสี่ยง ๆ bug และเอกสารที่เข้าใจยากจะเพิ่มขึ้น ทำให้ภาษาพัฒนาต่อไปอย่างมีประสิทธิภาพได้ยาก
    • ถ้าไม่ต้องใส่ใจเวอร์ชันของ Python ผมก็คิดว่า pip + venv เพียงพอแล้ว
      แต่ไม่มีวิธีกำหนดว่าโปรเจกต์ถูกสร้างขึ้นโดยอิงกับ Python เวอร์ชันไหน ถ้าคุณทำ package ก็มีแนวโน้มสูงว่าจะต้องทดสอบกับหลายเวอร์ชัน และถ้าไม่ใช่แพ็กเกจแจกจ่ายที่ติดตั้งได้ แต่เป็นชุดโค้ดที่นักพัฒนาบางคนแชร์กัน สำหรับงานอย่างรันโมเดล machine learning, deploy cloud function, หรือสร้างรายงาน โดยทั่วไปก็มักอยากเจาะจงเป้าหมายเป็น Python เวอร์ชันเดียวอย่างแม่นยำ
      ยังสงสัยด้วยว่าแนวทาง monorepo นี่หมายถึงการคัดลอก numpy กับ pandas ใส่ไว้ใน repository หรือเปล่า
    • ประสบการณ์ของผมก็เหมือนกันทุกประการ: pip เพียงพอสำหรับผม

  • ตอนแรกคาดหวังว่าเครื่องมือใหม่จะช่วยแก้ปัญหา “packaging” ของ Python ได้ แต่พออ่านเพิ่มแล้ว กลายเป็นเรื่องเกี่ยวกับ การจัดการ package มากกว่าปัญหาการห่อแอปพลิเคชัน Python ที่ผมสร้าง
    โดยส่วนตัวแล้วผมไม่ได้มีปัญหาใหญ่กับการจัดการ package ของ Python และถึง ecosystem จะมีจุดที่ขาดอยู่บ้าง แต่ถ้าไม่นับเรื่องอย่างการไม่มี namespace แล้ว pip ก็ทำงานได้ค่อนข้างดี
    สิ่งที่น่าหงุดหงิดจริง ๆ คือไม่สามารถห่อแอปพลิเคชัน Python ให้เป็นไฟล์ executable ได้ง่าย ๆ แล้วนำไป deploy ที่ไหนสักแห่งได้ ผมมักเห็นใน production ว่ามีการ git clone แล้วสร้าง virtualenv ซึ่งทำให้เซิร์ฟเวอร์ปลายทางต้องมีการเชื่อมต่อมากเกินจำเป็น และ dependency สำหรับพัฒนาก็อาจค้างอยู่ในระบบปฏิบัติการด้วย จากมุมมองด้านความปลอดภัย นี่เป็นไอเดียที่แย่มาก ดังนั้นจนกว่าปัญหานี้จะถูกแก้ ผมจะเลือกภาษาอื่นสำหรับงานที่ต้องส่งให้ผู้ใช้ปลายทางหรือ deploy ใน production

    • ที่พูดมาก็ไม่ได้ผิด แต่ถ้าแยกให้ชัด แก่นของเรื่องคือจำเป็นต้องทำให้คนอื่นรันแอปพลิเคชันได้ง่าย
      เพื่อให้เป็นแบบนั้น แอปพลิเคชันต้องถูกส่งถึงผู้ใช้ แล้วค้นหา Python ที่นั่น และกระบวนการนั้นต้องโปร่งใสสำหรับผู้ใช้ หนึ่งในเหตุผลที่ตอนสร้าง Rye และ uv ก็เช่นกัน เราพยายามรองรับ การติดตั้ง Python ในแบบที่ไม่ทำให้ระบบพัง ก็เพราะเรื่องนี้
      รูปแบบที่พัฒนาไปอีกขั้นคือทำให้ทั้งกระบวนการเป็นอัตโนมัติ รวมถึง uv ด้วย ตอนนี้ถ้าต้องการ ก็สามารถใช้ตัวติดตั้งแบบ curl to bash เพื่อติดตั้ง uv/Rye และแอปลงในตำแหน่งชั่วคราวเฉพาะของแอป และทำให้ไม่ทำลายระบบของผู้ใช้เลย
      หวังว่าสักวันกระบวนการนี้จะโปร่งใสอย่างสมบูรณ์ ไม่ต้องเข้าถึงเครือข่าย และมีอย่าง .msi สำหรับ Windows ด้วย อย่างไรก็ตาม เงื่อนไขก่อนหน้านั้นคือเครื่องมืออย่าง uv ต้องสามารถนำ Python ที่คอมไพล์ไว้ล่วงหน้าและ dependency ที่จำเป็นทั้งหมดไปวางในตำแหน่งที่เหมาะกับแพลตฟอร์มของผู้ใช้ได้ตามต้องการ
      โบนัสสุดท้ายที่ uv อาจมอบให้ได้ในสักวันคือผลลัพธ์ที่ถูกห่อมาอย่างสมบูรณ์ และถ้าเป็นเช่นนั้นก็คงดีมาก แค่ขั้นก่อนหน้านั้น ประสบการณ์ในการส่งมอบเครื่องมือ command-line ที่ทำด้วย Python ให้ผู้ใช้ก็อาจไม่เลวร้ายอีกต่อไปแล้ว จะใช้ uvx หรือถ้าต้องการก็ซ่อน uv เองทั้งหมดได้
    • ขึ้นอยู่กับว่าคุณจะติดตั้งอะไรที่ไหน แต่ถ้าเป็นเป้าหมายการ deploy ที่สมเหตุสมผล โดยปกติก็จะมีเครื่องมือสำหรับสร้าง binary ที่ติดตั้งได้ สำหรับเป้าหมายนั้น
      ตัวอย่างเช่นมีเครื่องมือที่สร้างตัวติดตั้งแยกตามระบบปฏิบัติการ และก็เริ่มมีเครื่องมือสำหรับ deploy ไปยังที่พิเศษ ๆ อย่าง Android, iOS หรือ browser ด้วย แน่นอนว่า package บางตัวอาจไม่ทำงานบนเป้าหมายบางอย่างได้ แต่เพราะมี interface มาตรฐาน ถ้าโค้ดสามารถรันที่ไหนสักแห่งได้ เครื่องมือสำหรับเป้าหมายนั้นก็ควรสร้างผลลัพธ์ที่ทำงานได้ให้ได้

  • หลังจากการ rug pull ที่ขับเคลื่อนด้วยเงินร่วมลงทุนของ npm, การถูก Microsoft ซื้อกิจการ และการที่ OpenAI แสดงให้เห็นว่าแม้แต่สถานะไม่แสวงหากำไรตามกฎหมายก็เป็นเพียงการตลาดที่ไร้พลังสำหรับผู้นำที่พันอยู่กับเส้นทางเงินร่วมลงทุนแล้ว ก็ทำให้ไม่อยากยก โครงสร้างพื้นฐานของภาษา ที่อยู่บนเส้นทางสำคัญให้แก่องค์กรแบบนี้
    บุคคลที่เข้ามามีส่วนร่วมในองค์กรเหล่านี้แต่ละคนยอดเยี่ยม และบ่อยครั้งก็โดดเด่น แต่ผลประโยชน์ทางการเงินในระดับองค์กรนั้นปนเปื้อนมาตั้งแต่ต้น พอผ่านไป 1–4 ปี สิ่งที่สำคัญคือองค์กรเอง ประมาณว่า “ตายอย่างฮีโร่ หรือมีชีวิตอยู่นานพอจนกลายเป็นวายร้าย”
    ดังนั้น linter ที่เร็ว, ตัวตรวจสอบ type, การสแกนโค้ด, เครื่องมือช่วย PR นั้นโอเค และเปลี่ยนได้ตลอด แต่ flow การติดตั้งกับ repository ของแพ็กเกจไม่ควรเป็นแบบนั้น
    เมื่อนึกถึงสภาพของ pip และ conda ก็รู้สึกน่าเสียดาย แต่คิดว่านี่คือความจริง

    • ใน Python ศึกนั้นแพ้ไปแล้ว
      ผมมองว่า Microsoft เป็นเจ้าของ Python อยู่ เพียงแต่ไม่ได้แสดงออกอย่างเปิดเผยเท่านั้น
      หลายปีก่อนผมอยากทำ Python binding สำหรับ kubectl แต่พบว่าถ้าจะให้ทำงานข้ามแพลตฟอร์มได้ CGo ต้องใช้ compiler เดียวกับ Python บนทุกแพลตฟอร์ม แต่บน Windows นั้น CGO ใช้ MINGW ส่วน Python ใช้ MSVC ตอนนั้นผมถามใน mailing list นักพัฒนา Python ที่มีอยู่ว่า ทำไมโปรเจกต์ “โอเพนซอร์ส” ถึงใช้ compiler แบบกรรมสิทธิ์ คำตอบที่ได้คือ MSVC เป็นตัวเลือกตามประวัติศาสตร์ และตอนนี้เปลี่ยนไม่ได้แล้ว คำอธิบายคือ Microsoft ให้โครงสร้างพื้นฐานฟรีแก่ Python Foundation สำหรับรัน CI และ build และยังให้ developer ที่ทำงานกับ Python interpreter ด้วย กล่าวคือพนักงาน Microsoft รับเงิน Microsoft มาทำงานกับ Python interpreter และได้รับคำสั่งว่าอย่าเอาเครื่องมือของ Microsoft ออกจาก toolchain
      สถานการณ์แย่ลงทุกปี เช่นเดียวกับโปรเจกต์ที่คล้ายกัน ความสำเร็จสร้างพื้นที่ให้คนที่ไม่ได้มีความสามารถพิเศษอะไรเข้ามาถืออำนาจ และโปรเจกต์รอบข้างอย่าง Python Foundation กับ PyPA ก็เริ่มเต็มไปด้วยคนที่ขึ้นมามีตำแหน่งไม่ใช่เพราะ contribute โค้ดที่มีประโยชน์ แต่เพราะเขียนหน้า code of conduct การทะเลาะไม่รู้จบเรื่อง code of conduct และการควบคุมตำแหน่งเหล่านี้ สุดท้ายทำให้ contributor เก่า ๆ ลาออกหรือถูกขับออกไป และเมื่อเร็ว ๆ นี้ Tim ผู้สร้าง Tim sort ก็ถูกแบนด้วย
      Microsoft ยังคงผลักดันวาระทั่วไปที่ทำกับทุกโปรเจกต์ที่เข้าไปแตะ คือเพิ่มฟีเจอร์ไร้ประโยชน์จำนวนมากเพื่อการโฆษณา ทำให้โปรเจกต์สั่นไหวไปทุกทิศทาง และโดยเฉพาะอย่างยิ่งทำให้ไล่ตามกระแสให้มากที่สุด ดังนั้นทั้งที่ Python เป็นภาษาที่มีระบบ type แตกต่างไปอย่างสิ้นเชิง ก็ยังพยายามเพิ่ม type แบบสาย machine learning ให้มากที่สุด และทั้งที่เป็นภาษาที่ถูกใช้ไปครึ่งหนึ่งกับการผูก native library แบบ dynamic ก็ยังไปหมกมุ่นกับการ precompile และ JIT โดยแก่นแล้วคือการทำให้มันเป็น C# แบบไม่มีวงเล็บปีกกา
      Microsoft ฉลาดพอที่จะรู้ว่า หากประกาศความเป็นเจ้าของ Python อย่างเปิดเผย หลายคนจะถอยห่างจากเทคโนโลยีนี้ จึงไม่โฆษณาใหญ่โต แต่ก็ยังคงทำให้ developer พึ่งพาเครื่องมือของตนต่อไป และสักวันหนึ่งก็จะมาเก็บผลตอบแทนจากเงินลงทุนก้อนนั้น
    • npm เดิมก็เป็นบริษัทอยู่แล้วไม่ใช่หรือ? ไม่รู้ว่า rug pull ที่ว่าคืออะไร และมีอะไรที่หยุดทำงานจริง ๆ หรือเปล่า?
    • ถ้า PSF กับ PyPA ตั้งสติแล้วออกมาพูดเรื่องดี ๆ เกี่ยวกับ Python packaging ก็ยินดีเสมอ
      แต่สิ่งที่ปล่อยออกมาจนถึงตอนนี้ โดยแก่นแล้วมีแค่โพสต์บล็อกจาก contributor เป็นพันล้านชิ้นในทำนองว่า “ระบบที่เราสร้างขึ้นจำกัดไม่ให้เราช่วยเหลือได้ และอย่างไรก็ไม่ใช่ความผิดของเรา”
      ดูเหมือนพวกเขาจมอยู่กับระบบภายในและการเมืองภายในมากจนไม่รู้แล้วว่าตัวเองอยู่ตรงนั้นไปเพื่ออะไร
      ดังนั้นถ้ามีใครทำได้ดีจริง ๆ และครองตลาดได้เหมือน Astral นั่นก็คือผลลัพธ์ที่พวกเราในฐานะชุมชนสมควรได้รับ
      [1]: ที่พูดถึงตรงนี้คือการเมืองภายใน ไม่ใช่การโวยวายแบบขวาจัดแปลก ๆ ว่า “จ้างงานแบบ DEI!”

  • เครื่องมือเหล่านี้ยังมีปัญหาเรื่อง authority อยู่
    มันต่างจาก cargo ตรงที่ไม่ได้รับการอนุมัติจาก PyPA ขณะเดียวกัน PyPA ก็ไม่สามารถเสนอทางออกแบบครอบคลุมได้มาหลายปีแล้ว และเครื่องมือ packaging กับ development ของ Python ก็เพิ่มจำนวนขึ้นเรื่อย ๆ เมื่อแค่ 3–4 ปีก่อน poetry กับ pipenv ยังดูเหมือนจะแก้ปัญหา Python packaging ที่ pip+virtualenv แก้ไม่ได้
    ตอนนี้ผมคิดว่า PyPA ควรขึ้นเรือ astral.sh แต่ก็ไม่รู้ว่าจะทำเช่นนั้นโดยไม่มีอำนาจควบคุมในระดับหนึ่งหรือไม่

    • เพิ่งรู้เมื่อไม่นานมานี้ว่า Authority ในชื่อ PyPA คือ Python Packaging Authority เดิมทีตั้งใจให้เป็นมุก: https://discuss.python.org/t/remove-the-authority-from-packa...
    • ตั้งแต่ตอนที่ PyPA รับรอง Pipenv แทนตัวเลือกอื่น ๆ ผมก็เลิกสนใจคำแนะนำของ PyPA แล้ว
      ในมุมของผม ส่วนใหญ่เป็นเพราะความสัมพันธ์ส่วนตัว และตอนนั้น Pipenv เป็นหายนะ แม้เจตนาดี แต่ที่บริษัท แม้แต่ repository ที่มี dependency ที่ใช้กันทั่วไปจำนวนไม่มากนัก ก็ยังต้องรอเป็นชั่วโมงเพื่ออัปเดต lock file มันใช้งานไม่ได้จริง ๆ
      ในเชิงปฏิบัติ ผมขอบคุณงานเทคนิคยาก ๆ ที่ PyPA ทำอย่างมาก แต่ตอนนี้ไม่ค่อยสนใจแล้วว่าเขาแนะนำชุดเครื่องมืออะไร ผมคิดว่าดีกว่าที่จะใช้สิ่งที่ชุมชนใช้กัน และไม่ต้องกังวลกับข้อเสนอที่เป็น “ทางการ”
    • จากมุมของคนนอกเล็กน้อย ผมไม่ค่อยเข้าใจว่า PyPA คืออะไรกันแน่
      จำนวนผู้เข้าร่วมไม่ชัดเจน และก็ไม่แน่ใจว่า PyPA เกี่ยวข้องกับ core Python หรือ PSF มากน้อยแค่ไหน
      ผมคิดว่าการรับรองที่จะช่วยได้จริงควรมาจากโปรเจกต์ core Python เอง ในโลกอุดมคติ tutorial ทางการของ Python ควรเริ่มด้วย “วิธีติดตั้ง Python คือแบบนี้” แล้วแนะนำให้ติดตั้ง uv ตั้งแต่ต้น คล้ายกับที่เอกสารทางการของ Rust ชี้ไปที่ rustup และ cargo
      หวังอย่างแรงว่า PSF จะสร้างความสัมพันธ์บางอย่างกับ Astral เพื่อให้วันหนึ่งความเป็นจริงแบบนี้เกิดขึ้นได้
    • พูดตรง ๆ ตอนนี้ผมไม่สนใจ PyPA แล้ว
      ในบริบทนี้ ผมคิดว่าพวกเขาพิสูจน์เองแล้วว่าโดยรวมไม่เกี่ยวข้อง อะไรก็ตามที่เข้าไปแตะดูเหมือนจะเน่าเสียไปหมด จึงน่าเสียดาย แต่ผมอยากให้พวกเขาอยู่ห่างจากปัญหานี้ การพูดแบบนี้ทำให้ลำบากใจและขัดกับปรัชญาของผมเอง แต่เป็นเพียงการตัดสินตามสภาพปัจจุบันเท่านั้น ผมทำงาน full-time ด้วย Python มา 10 ปี และ ecosystem packaging อื่น ๆ แซงหน้า Python ไปมากกว่าหนึ่งรอบแล้วในทางปฏิบัติ
      ตอนนี้ผมไม่สนใจ nuance อย่าง “เป็นปัญหาการ execute ของ PyPA หรือขอบเขตบทบาทที่กำหนดไว้ผิด” อีกแล้ว เบื่อที่จะถูกลากเข้าไปในบทสนทนาแบบนั้นด้วย

  • Armin สนับสนุนให้ uv ครองพื้นที่นี้ แต่ก็ยอมรับด้วยว่าเพราะอิงกับเงินลงทุนจาก VC จึงอาจเกิด rug pull ได้
    เขาบอกว่า “ฟอร์กได้ง่ายมาก” เป็นทางออกสำหรับปัญหาที่อาจเกิดขึ้นนี้ แต่การฟอร์กโดยธรรมชาติแล้วไม่ได้ทำให้เกิดการแตกกระจายมากขึ้นหรือ? ก็นั่นแหละคือปัญหาที่เขาอยากแก้
    ถ้าเป็นเครื่องมือที่ตั้งใจจะครองภูมิทัศน์ของ Python packaging ผมคิดว่าควรขับเคลื่อนโดยชุมชนและถูกควบคุมโดยชุมชน

    • การฟอร์กไม่ได้ทำให้เกิดการแตกกระจายมากขึ้นโดยธรรมชาติเสมอไป
      ระดับการแตกกระจายหลังจากที่เครื่องมือซึ่งถูก rug pull ได้รวมศูนย์ไปแล้ว อาจต่ำกว่าก่อนการรวมศูนย์มากก็ได้
      แล้วชุมชนในจินตนาการนี้ยังต้องใช้เวลาอีกกี่สิบปีถึงจะสร้างเครื่องมือหลักที่ยอดเยี่ยมได้?
    • การเลือกไลเซนส์เป็น MIT หรือ Apache อาจทำให้ฟอร์กได้ง่าย แต่ การเลือก Rust จำกัดจำนวนคนที่สามารถมีส่วนร่วมได้จริง
    • npm ก็อิงกับเงินลงทุนจาก VC ไม่ใช่หรือ?

  • เมื่อเช้านี้ที่บริษัท ผมลองดูการ ย้ายซอฟต์แวร์ของเราจาก Poetry ไป uv เพราะ Poetry ช้า
    จนถึงตอนนี้อ่านเอกสารไปเยอะ แต่ยังไม่ค่อยมีความคืบหน้าจริง ๆ มากนัก ก่อนหน้านี้ผมก็เป็นคนย้ายไป Poetry เอง ซึ่งตอนนั้นง่ายกว่านี้มาก เท่าที่ดูมาจนถึงตอนนี้ Poetry พยายามทำตัวเป็น package manager แบบเรียบง่ายที่ทำงานเหมือน package manager อื่น ๆ ส่วน uv ดูเหมือนจะยังคงความบ้าคลั่งของแพ็กเกจ Python ไว้ค่อนข้างมาก

    • อย่างน้อย uv ก็ไม่ไปชนกับ virtualenv จนกลายเป็นความยุ่งเหยิงเต็มรูปแบบเหมือน Poetry
      และไม่มีกรณีที่การเปลี่ยนเล็กน้อยของ Poetry ทำให้รูปแบบ package.toml พัง หรือทำให้เวลา resolve จากหลาย index นานขึ้นเพราะ “sources” โง่ ๆ ที่ใช้กับ transitive dependency ไม่ได้
    • แชร์ได้ไหมว่าอะไรใน uv ที่ยากเป็นพิเศษ?
    • เพิ่งย้ายจาก pip-tools ไป uv เมื่อไม่นานมานี้ และค่อนข้างราบรื่น
      uv ให้ความรู้สึกเหมือนเสียบเข้ากับ โฟลว์เครื่องมือ Python มาตรฐาน ได้แทบจะตรง ๆ
    • ตอนนี้ uv ยัง low-level เกินไป บางทีคุณอาจกำลังต้องการ Rye อยู่หรือเปล่า?
    • ความบ้าคลั่งที่ว่าคือเรื่องอะไร?

  • ผมคงไม่โทษคนที่ข้ามรอบนี้ไป แล้วรอเวอร์ชันปี 2026 ของ “Python package manager: คราวนี้แก้ได้จริงแล้ว!”
    ถึงอย่างนั้นผมก็ยังเป็น ผู้ใช้ Nix ที่พอใจอยู่ดี

  • ผมชอบ framing แบบนี้มาก
    เพราะงานที่คนจำนวนมากค่อย ๆ สั่งสมมาเป็นเวลานาน ตอนนี้เราจึงมาถึงจุดที่คนเพียงไม่กี่คนในบริษัทเดียวสามารถปรับปรุงสถานการณ์ได้อย่างฉับพลันด้วยความพยายามระดับปานกลาง