หลังจากถกเถียงอย่างเข้มข้นนาน 4 ปี และข้อเสนอที่ล้มเหลวไป 2 ครั้ง ในที่สุดชุมชนผู้พัฒนา Python packaging ก็ได้กำหนดมาตรฐานรูปแบบ lock file ขึ้นแล้ว ข้อกำหนดใหม่ pylock.toml ที่ได้รับการยอมรับนี้มีเป้าหมายเพื่อสร้างความสม่ำเสมอในการจัดการ dependencies แต่การเดินทางครั้งนี้เผยให้เห็นความตึงเครียดในระดับลึกเกี่ยวกับการพัฒนาของชุมชนโอเพนซอร์ส และว่าวิธีการที่ขับเคลื่อนด้วยฉันทามตินั้นทันต่อความต้องการของการพัฒนาในยุคสมัยใหม่ได้หรือไม่
เส้นทางยาวไกลสู่การกำหนดมาตรฐาน
การตามหาข้อกำหนด lock file สำหรับ Python เริ่มต้นขึ้นในปี 2019 และกินเวลายาวนานผ่านข้อเสนอมากมาย การอภิปรายนับไม่ถ้วน และโพสต์ในฟอรัมกว่า 1,800 รายการ กระบวนการนี้เห็น PEP (Python Enhancement Proposals) หลักสองตัวคือ PEP 665 และ PEP 751 โดยตัวแรกถูกปฏิเสธเนื่องจากมีความเข้มงวดเกินไปด้วยการไม่รวม source distributions และตัวหลังได้รับการเขียนใหม่ทั้งหมดสามครั้งเพื่อรองรับความต้องการของเครื่องมือที่แตกต่างกัน ข้อกำหนดสุดท้ายรองรับการล็อกหลายแพลตฟอร์มและจัดการรูปแบบ dependencies ทั้งสามรูปแบบ ได้แก่ source trees, source distributions (sdists) และ wheels การเดินทางที่ซับซ้อนครั้งนี้เน้นย้ำถึงความท้าทายในการสร้างฉันทามติภายในระบบนิเวศที่หลากหลาย ซึ่งเครื่องมือต่างๆ มีแนวทางและข้อกำหนดที่แตกต่างกันโดยพื้นฐาน
ไทม์ไลน์ของ Lock File:
- 2019: การอภิปรายเริ่มต้นขึ้น (106 โพสต์ในฟอรัม)
- 2021: เสนอ PEP 665 ซึ่งรองรับเฉพาะ wheels (359 โพสต์)
- 2022: PEP 665 ถูกปฏิเสธ (106 โพสต์)
- 2023: ความพยายามเดี่ยวใหม่เริ่มต้นขึ้น (54 โพสต์)
- 2024: ร่างแรกของ PEP 751 และเปิดตัว uv (974 โพสต์)
- 2025: PEP 751 ได้รับการยอมรับ (150+ โพสต์)
ความไม่พอใจของชุมชนต่อระบบราชการ
ตลอดกระบวนการมาตรฐานที่ยาวนาน สมาชิกในชุมชนได้แสดงความไม่พอใจที่เพิ่มขึ้นต่อสิ่งที่บางคนมองว่าเป็นระบบราชการที่มากเกินไป ผู้แสดงความคิดเห็นหนึ่งคนสรุปความรู้สึกนี้ได้อย่างตรงจุด:
ด้วย Python/Django คุณจะเรียนรู้ว่าไม่ควรรอ เพราะไม่มีอะไรจะเปลี่ยนแปลง
ความหงุดหงิดนี้มาจากการเฝ้าดูระบบนิเวศอื่นๆ ก้าวไปข้างหน้าอย่างรวดเร็ว ในขณะที่แนวทางที่ขับเคลื่อนด้วยฉันทามติของ Python บางครั้งนำไปสู่การอภิปรายเป็นปีๆ โดยปราศจากข้อสรุป การถกเถียงเรื่อง lock file กลายเป็นตัวแทนของคำถามที่ใหญ่กว่าเกี่ยวกับโมเดลการปกครองของ Python หลังจากที่ Guido van Rossum พ้นจากตำแหน่ง BDFL (Benevolent Dictator For Life) สมาชิกชุมชนบางส่วนแย้งว่าการขาดผู้ตัดสินใจขั้นสุดท้ายได้ชะลอความก้าวหน้าหลายด้าน ตั้งแต่การปรับปรุง packaging ไปจนถึงการสนับสนุน async และการพัฒนา REST API ใน Django
ปัจจัย UV: การสร้างในขณะที่คนอื่นถกเถียง
การปรากฏตัวของ uv ในเดือนกุมภาพันธ์ 2024 ได้เปลี่ยนบทสนทนาเกี่ยวกับ lock file ไปอย่างสิ้นเชิง สร้างโดย Astral ด้วยภาษา Rust, uv ได้แสดงให้เห็นว่าเครื่องมือ Python ประสิทธิภาพสูงเป็นไปได้โดยไม่ต้องรอการกำหนดมาตรฐาน แม้ว่า uv จะได้รับประโยชน์จาก PEP ที่มีอยู่แล้ว แต่ผู้พัฒนาของมันได้แรงบันดาลใจจากภาษาอื่นๆ เช่น Cargo ของ Rust และให้ความสำคัญกับการสร้างซอฟต์แวร์ที่ทำงานได้จริงเหนือการอภิปรายในคณะกรรมการที่ไม่รู้จบ การยอมรับที่รวดเร็วของเครื่องมือนี้สร้างแรงกดดันให้มีการกำหนดมาตรฐาน ในขณะเดียวกันก็ลดความเร่งด่วนลง — ตอนนี้ผู้พัฒนามีทางแก้ไขที่ใช้งานได้แล้ว แม้ว่ามันจะไม่ได้ถูกกำหนดมาตรฐานในทุกเครื่องมือก็ตาม
การประนีประนอมด้านการทำงานร่วมกัน
แม้จะมีข้อกำหนดใหม่แล้ว uv จะยังคงใช้รูปแบบ uv.lock ของตัวเองสำหรับโปรเจกต์ต่อไป แต่มันรองรับ pylock.toml เป็นเป้าหมายสำหรับการส่งออก การยอมรับเพียงบางส่วนนี้สะท้อนถึงความท้าทายในการสร้างโซลูชันที่เหมาะกับทุกคนในระบบนิเวศที่หลากหลาย เครื่องมือหลักทั้งสามตัวที่เกี่ยวข้อง — uv, Poetry และ PDM — มีความต้องการที่แตกต่างกันซึ่งทำให้การบรรลุฉันทามติโดยสมบูรณ์เป็นเรื่องยาก PDM ได้ปรับใช้การรองรับ pylock.toml แล้ว แสดงให้เห็นว่าข้อกำหนดดังกล่าวตอบโจทย์ความต้องการของบางโปรเจกต์ ในขณะที่การสนับสนุนบางส่วนของ uv แสดงให้เห็นว่าข้อกำหนดดังกล่าวยังไม่เพียงพอสำหรับกรณีการใช้งานขั้นสูงกว่า
สถานะการรองรับของเครื่องมือ:
- PDM: รองรับ pylock.toml อย่างเต็มรูปแบบแล้ว
- uv: รองรับบางส่วน (เฉพาะ export target และ uv pip CLI เท่านั้น)
- pip: มีการรองรับในระดับหนึ่ง
- Poetry: เป็นผู้เข้าร่วมหลักในกระบวนการกำหนดมาตรฐาน
การอภิปรายเรื่อง Semver และการจัดการ Dependencies
เหนือไปจากรูปแบบของ lock file เอง การอภิปรายยังเผยให้เห็นความกังวลในระดับลึกเกี่ยวกับปรัชญาการจัดการ dependencies ของ Python ผู้แสดงความคิดเห็นบางคนตั้งคำถามว่า lock file เป็นการยอมแพ้ในเรื่องความยืดหยุ่นของเวอร์ชันแพ็กเกจหรือไม่ ในขณะที่บางคนปกป้องว่ามันเป็นสิ่งจำเป็นสำหรับการสร้างที่ทำซ้ำได้ (reproducible builds) บทสนทนาได้触及 ถึงการปฏิบัติ semantic versioning (semver) ในระบบนิเวศ Python โดยบางคนตั้งข้อสังเกตว่าแพ็กเกจจำนวนมากไม่ได้ปฏิบัติตาม semver อย่างเคร่งครัด ทำให้การแก้ไข dependencies เป็นเรื่องท้าทายเป็นพิเศษ บริบทที่กว้างขึ้นนี้ช่วยอธิบายว่าทำไม lock file ถึงกลายเป็นประเด็นที่ถกเถียงกันอย่างรุนแรง — มันแสดงถึงการเปลี่ยนแปลงขั้นพื้นฐานในวิธีที่นักพัฒนา Python จัดการ dependencies
การเดินทาง 4 ปีสู่ข้อกำหนด lock file แสดงให้เห็นทั้งจุดแข็งและจุดอ่อนของแนวทางที่ขับเคลื่อนโดยชุมชนของ Python ในขณะที่กระบวนการดังกล่าวรับประกันการมีส่วนร่วมที่กว้างขวางและการพิจารณากรณีการใช้งานที่แตกต่างกันอย่างรอบคอบ แต่มันก็แสดงให้เห็นด้วยว่าการบรรลุฉันทามติในระบบนิเวศที่พัฒนาอย่างรวดเร็วนั้นยากเพียงใด ดังที่ผู้แสดงความคิดเห็นหนึ่งคนระบุไว้ วิธีแก้ปัญหาที่ดีที่สุดมักมาจากการสร้างซอฟต์แวร์ที่ทำงานได้จริง มากกว่าการอภิปรายที่ไม่รู้จบ — บทเรียนที่อาจกำหนดอนาคตการ packaging ของ Python มากกว่าข้อกำหนดใดๆ เพียงข้อเดียว
อ้างอิง: Why it took 4 years to get a lock files specification