Ruff 0.17.0 เซ็นรับรองไฟล์แล้ว แต่เกณฑ์ตรวจ Python เปลี่ยนด้วย

Ruff 0.17.0 เพิ่มลายเซ็นรับรองไฟล์บน macOS และ Windows แล้ว แปลว่าตรวจผู้เผยแพร่และความครบถ้วนของไฟล์ได้ ตามประกาศ Astral ที่ระบุวันออกเมื่อ 9 ต.ค. 2026 แต่รอบนี้เปลี่ยนเกณฑ์ตรวจโค้ดด้วย คนที่อัปเดตตามเพื่อนในห้องเรียนหรือทีมงานจึงควรอ่านมากกว่าบรรทัดว่าแก้บั๊กครับ

Ruff คือเครื่องมือตรวจและจัดรูปแบบโค้ด Python ภาษาที่ใช้เขียนโปรแกรม โดยงานตรวจเรียกว่า linter ส่วนงานจัดรูปแบบให้อ่านเป็นระเบียบเรียกว่า formatter ตามเอกสาร Astral บทความนี้อ่านจากประกาศและคู่มือย้ายระบบ ยังไม่ได้ทดลองกับโครงการจริง จึงแยกสิ่งที่ผู้พัฒนาระบุออกจากคำแนะนำก่อนอัปเกรดให้ชัดครับ

สรุป 30 วินาที: เกิดอะไรขึ้น

ข่าวหลักคือไฟล์โปรแกรมในชุดดาวน์โหลดและแพ็กเกจ wheel ซึ่งเป็นชุดติดตั้งของ Ruff บนระบบที่กล่าวถึง มีลายเซ็นดิจิทัลแล้ว Astral ระบุว่าช่วยตรวจว่าใครเผยแพร่ไฟล์ และตรวจความครบถ้วนของตัวโปรแกรม พร้อมรองรับการอนุญาตใช้งานตามผู้เผยแพร่ในองค์กร ตามบันทึกการออกรุ่น

อีกเรื่องที่ต้องจำคือ Python 3.11 แปลว่า Ruff ใช้รุ่นนี้เป็นเป้าหมายเริ่มต้นเมื่อโครงการไม่ได้ระบุรุ่นไว้ ตามประกาศเดียวกัน ส่วนการตรวจความผิดของไวยากรณ์ใช้ค่าเริ่มต้นอีกชุดหนึ่ง จึงต้องแยกสองเรื่องนี้ก่อนอ่านผลตรวจครับ

สำหรับคนเขียนผ่าน VS Code โปรแกรมแก้ไขโค้ดที่มีส่วนเสริมเพิ่มความสามารถ ส่วนเสริม Ruff จะใช้ระบบเชื่อมต่อแบบใหม่เสมอแล้ว การรองรับระบบเก่าถูกถอดออก ตามประกาศรุ่น และคู่มือย้ายระบบ ดังนั้นการติดตั้งรุ่นใหม่กับการตรวจค่าตั้งเดิมควรทำไปด้วยกัน

เหตุผลที่ขยับรุ่นเริ่มต้นอยู่ใน PR #28792 ของ Ruff ซึ่งเขียนว่าปรับค่าเริ่มต้นเป็น Python 3.11 ให้สอดคล้องกับที่ Python 3.10 ใกล้หมดระยะดูแล และปรับรุ่นล่าสุดที่รู้จักเป็น 3.15 แปลว่านี่เป็นการเดินตามรอบอายุของ Python ไม่ใช่การบังคับให้ทุกโปรเจกต์ต้องย้ายรุ่นทันทีครับ

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

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

สำหรับทีมไทยที่มีระบบงานอยู่แล้ว ความเสี่ยงที่ควรทดสอบคือเกณฑ์ในเครื่องนักพัฒนาตรงกับเกณฑ์ที่ทีมต้องการหรือไม่ หากยังรองรับ Python รุ่นเก่า การปล่อยค่าเป้าหมายว่างมีความหมายต่างจากเดิม ตามประกาศ คำแนะนำคือให้ผู้รับผิดชอบโครงการระบุความต้องการนี้อย่างชัดเจน แทนการให้แต่ละคนเดาเอง

แล้วคำเตือนที่ลดลงหมายถึงงานปลอดภัยขึ้นเสมอหรือเปล่า? คำตอบคือยังสรุปแบบนั้นไม่ได้ เพราะรายการเปลี่ยนแปลง บอกว่ากฎบางข้อเลิกเปิดเป็นค่าเริ่มต้นด้วย จำนวนคำเตือนจึงต้องอ่านคู่กับรายชื่อกฎที่ใช้ครับ

ทำงานยังไง

Code signing คือลายเซ็นดิจิทัลกำกับไฟล์โปรแกรมเพื่อช่วยตรวจผู้เผยแพร่และความครบถ้วนของไฟล์ บน macOS ทาง Astral ใช้ใบรับรอง Apple Developer ID และผ่านกระบวนการรับรองที่เรียกว่า notarization ของ Apple ตามประกาศรุ่น นี่เป็นรายละเอียดของการแจกไฟล์ ไม่ใช่การเปลี่ยนหน้าตาโค้ดของเรา

บน Windows ไฟล์มีลายเซ็น Authenticode พร้อมข้อมูลเวลา ผ่านบริการ Azure Artifact Signing ตามประกาศ Astral ผู้พัฒนาระบุว่ารองรับ publisher-based allowlisting หรือการตั้งกฎอนุญาตโปรแกรมตามผู้เผยแพร่ และคาดว่าจะลดการเตือนด้านความปลอดภัยที่ผิดพลาด รวมถึงกรณีโปรแกรมป้องกันไวรัสเข้าใจผิดว่าไฟล์เป็นภัย

อีกส่วนหนึ่งคือเกณฑ์ภาษา ค่า target-version หมายถึงรุ่น Python ที่โครงการต้องการให้เครื่องมือตรวจยึดเป็นเป้าหมาย ส่วน requires-python ระบุรุ่น Python ที่โครงการต้องการ ตามเงื่อนไขในบันทึกการออกรุ่น เป้าหมายเริ่มต้นเดิมคือ Python 3.10 แปลว่าโครงการที่ปล่อยรุ่นว่างเคยยึดเกณฑ์รุ่นนี้ ตามประกาศ การเปลี่ยนเกิดเมื่อไม่ได้กำหนดผ่านสองทางนี้ จึงไม่ได้แปลว่าทุกโครงการถูกเปลี่ยนเป้าหมายพร้อมกัน

สำหรับการตรวจไวยากรณ์โดยไม่มีรุ่นกำกับ ค่าใหม่คือ Python 3.15 แปลว่าเกณฑ์ตรวจรูปประโยคของภาษาส่วนนี้ยึดรุ่นดังกล่าว ตามประกาศ ค่าเดิมของการตรวจส่วนนี้คือ Python 3.14 แปลว่าเกณฑ์ไวยากรณ์ขยับจากรุ่นก่อน ตามประกาศเดียวกัน เรื่องนี้ต้องแยกจากเป้าหมายทั่วไป และไม่ควรอ่านว่าอัปเดต Ruff แล้ว Python ที่ติดตั้งอยู่จะเปลี่ยนตาม

เปรียบเหมือน ครูตรวจการบ้านที่เปลี่ยนเกณฑ์ตรวจและเริ่มเซ็นชื่อกำกับใบตรวจ ครับ ลายเซ็นช่วยรู้ว่าใบตรวจมาจากครูคนไหน ส่วนเกณฑ์บอกว่าการบ้านต้องผ่านอะไร การเซ็นชื่อไม่ได้ทำให้โจทย์เดิมหายยาก และคำติที่น้อยลงอาจมาจากครูเลิกตรวจบางข้อ อุปมานี้ช่วยแยกการรับรองไฟล์ออกจากการเปลี่ยนกฎในประกาศ Ruff

จุดหักมุม: เห็นคำแนะนำมากขึ้น แต่ยังไม่ได้อนุญาตให้แก้ทุกอย่าง

แต่ผลบนหน้าจออาจดูเข้มขึ้น ทั้งที่คุณยังไม่ได้เปิดการแก้แบบเสี่ยงครับ Astral เปลี่ยนผลลัพธ์เต็มของ CLI หรือหน้าจอเรียกคำสั่ง ให้แสดงการแก้แบบ unsafe และข้อเสนอที่ต้องตรวจเองเสมอ ตามบันทึกรุ่น

Unsafe fix คือการแก้ที่ต้องระวังผลต่อพฤติกรรมโค้ด ส่วน display-only fix เป็นคำแนะนำที่แสดงให้พิจารณา การนำการแก้แบบ unsafe ไปใช้ยังต้องเปิดยอมรับอย่างชัดเจน ตามประกาศ เห็นข้อเสนอจึงไม่ได้แปลว่าโปรแกรมแก้ให้แล้ว

อีกด้านคือกฎ F406 เปิดเป็นค่าเริ่มต้นแล้ว แปลว่า Ruff ตรวจกรณีการใช้ import แบบดาวในขอบเขตซ้อนที่เกี่ยวกับความผิดไวยากรณ์ ตามรายการเปลี่ยนแปลง แต่กฎกลุ่ม DTZ เกี่ยวกับวันเวลาและเขตเวลาหลายข้อกลับเลิกเปิดเริ่มต้น ผลตรวจรอบใหม่จึงมีทั้งจุดที่เพิ่มและจุดที่ลดครับ

เรื่องเงิน / ผลกระทบ

แหล่งข้อมูลที่อ่านไม่ได้ให้ตัวเลขว่าลายเซ็นช่วยลดเวลางานหรือค่าใช้จ่ายเท่าไรครับ Astral ระบุ เพียงว่าควรลดคำเตือนผิดพลาด จึงยังแปลงเป็นเงินที่ทีมไทยประหยัดได้ไม่ได้ สิ่งที่ควรเผื่อในแผนอัปเดตคือเวลาทดสอบผลตรวจและตรวจการตั้งค่าของทีม

เรื่องที่อาจทำให้ขั้นตอนเดิมหยุดใช้ได้อยู่ใน conda-forge ช่องทางแจกแพ็กเกจที่มีชุด Ruff ของตัวเอง ชุดนี้เลิกพึ่ง Python แล้ว และเรียก python -m ruff หรือ import ruff ไม่ได้อีก ตามประกาศ วิธีที่ผู้พัฒนาระบุคือเรียก ruff โดยตรงจาก PATH หรือรายชื่อที่อยู่ซึ่งระบบใช้ค้นหาโปรแกรม

ข้อจำกัดนี้มีขอบเขตครับ Astral ระบุว่าการติดตั้งผ่าน PyPI แหล่งแพ็กเกจ Python และตัวติดตั้งแยกไม่ได้รับผลกระทบจากการเปลี่ยนดังกล่าว ตามบันทึกรุ่น ก่อนแก้คำสั่งทั้งทีม จึงควรสำรวจว่าแต่ละสภาพแวดล้อมติดตั้งมาจากช่องทางไหน

สำหรับคนดูแลรูปแบบโค้ด คอมเมนต์ท้ายบรรทัดประเภท pragma หรือข้อความกำกับการทำงานของเครื่องมือ จะไม่นับรวมในการคำนวณความยาวบรรทัดอย่างสอดคล้องกันแล้ว ทั้ง formatter และกฎที่เกี่ยวข้อง ตามประกาศ ผู้พัฒนาเตือนว่ารายการนำเข้าโค้ดจากส่วนอื่น หรือ imports ที่มีอยู่ อาจถูกจัดรูปแบบใหม่ จึงจัดเรื่องนี้เป็นการเปลี่ยนที่กระทบพฤติกรรมเดิม

อีกชุดการเปลี่ยนเป็นเรื่องตัวอักษรและกฎเฉพาะทาง Ruff ใช้ข้อมูล Unicode 17 แล้ว แปลว่าข้อมูลมาตรฐานตัวอักษรสำหรับปรับรูปชื่อและอ้างอักขระตามชื่อเปลี่ยนเป็นชุดนี้ ตามบันทึกรุ่น ประกาศยังระบุว่าชื่อตัวแปรที่ขึ้นต้นด้วยขีดล่างและใช้ตัวอักษร Unicode ถูกยอมรับเป็นชื่อตัวแปรที่ตั้งไว้ไม่ใช้งานตามค่าเริ่มต้น

กฎ TID254 สำหรับการนำเข้าแบบ lazy ที่ไม่ตรงกันพ้นช่วงทดลองแล้ว ตามประกาศ คำว่า lazy import หมายถึงการนำเข้าส่วนของโปรแกรมแบบเลื่อนการทำงาน ส่วน TID255 สำหรับกรณีที่การนำเข้าแบบนี้ถูกคลี่ใช้งานทันที ก็พ้นช่วงทดลองเช่นกันตามแหล่งเดียวกัน แต่ประกาศที่อ่านไม่ได้อธิบายผลด้านความเร็ว จึงยังใช้ยืนยันว่าระบบของเราจะเร็วขึ้นไม่ได้

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

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

ฝั่งที่ชี้ภาระการย้ายคือคู่มือ Astral Docs ซึ่งบอกให้ย้ายค่าตั้งที่เลิกใช้ ลบค่าที่ไม่รองรับ และอัปเดต Ruff ตามคู่มือ นี่เป็นข้อจำกัดจากผู้พัฒนาเอง ไม่ใช่เสียงค้านอิสระ แหล่งที่ได้รับไม่มีองค์กรภายนอกออกมาคัดค้าน จึงไม่มีเหตุผลจะสร้างฝ่ายที่เห็นต่างขึ้นมาให้ครบรูปข่าวครับ

ในข้อมูลที่อ่าน ไม่พบวันที่หรือตัวเลขที่สองเอกสารขัดกัน แต่ขอบเขตต่างกัน ประกาศรุ่นบอกว่าถอดการรองรับ ruff-lsp ระบบเชื่อม Ruff กับตัวแก้ไขโค้ดแบบเก่า และค่าตั้ง ruff.nativeServer ถูกเลิกใช้พร้อมถูกมองข้าม ตามประกาศ ส่วนคู่มือย้ายระบบ อธิบายขั้นตอนเปลี่ยนค่าตั้งจากระบบเก่าไปใหม่ จึงควรอ่านประกอบกัน ไม่ใช่เลือกเชื่อเพียงหน้าเดียว

Native server คือระบบเชื่อมต่อที่อยู่ใน Ruff เอง เขียนด้วย Rust ซึ่งเป็นภาษาโปรแกรมอีกภาษา และเรียกได้ผ่าน ruff server ตามคู่มือ Astral ส่วนระบบเก่าเขียนด้วย Python และเป็นแพ็กเกจแยก คู่มืออธิบายประวัติและวิธีย้าย แต่ข้อความที่อ่านไม่ได้ระบุวันเผยแพร่คู่มือ จึงไม่ควรตั้งวันที่ให้ตรงกับวันออกรุ่นเอง

แล้วห้องเรียนหรือบริษัทของเราต้องแก้กี่จุด? ยังตอบแทนไม่ได้ เพราะแหล่งข้อมูลไม่ได้มีค่าตั้งหรือผลทดสอบของแต่ละโครงการครับ ควรเปิดรายการค่าจริงก่อน โดยเฉพาะค่าที่คู่มือบอกว่าไม่รองรับ บทความนี้จึงเป็นแผนตรวจจากเอกสาร ไม่ใช่รายงานว่าทดลองครบทุกสภาพแวดล้อมแล้ว

แล้วเราควรทำอะไร

นักเรียนและคนเริ่มเขียน Python

1. ดูรุ่นที่บทเรียนตั้งใจใช้ก่อนอัปเดต ถามผู้สอนว่าโครงการควรยึด Python รุ่นไหน แล้วตรวจว่ามี target-version หรือ requires-python กำกับหรือไม่ เพราะประกาศ Astral ระบุว่าค่าเริ่มต้นใหม่ใช้เมื่อไม่มีการตั้งรุ่น คำแนะนำคือให้ยึดความต้องการของบทเรียนก่อนค่าของเครื่องมือ
2. แยกการตรวจออกจากการแก้ ลอง ruff check เพื่ออ่านผลก่อน แล้วค่อยพิจารณาคำแนะนำทีละส่วน การแสดง unsafe fix ไม่ได้หมายความว่าเปิดอนุญาตแล้ว ตามเงื่อนไขในประกาศ อย่าเพิ่มการยอมรับการแก้แบบเสี่ยงเพียงเพื่อให้ข้อความบนจอหายครับ
3. ทบทวนส่วนเสริม VS Code ถ้าเคยคัดลอกค่าตั้งจากบทเรียนเก่า ให้ตรวจตามคู่มือย้ายระบบ ก่อน ค่าเดิมที่เก็บไว้อาจไม่ได้ทำงานเหมือนที่ผู้เขียนบทเรียนตั้งใจ ไม่จำเป็นต้องแก้ทุกค่าพร้อมกันโดยยังไม่รู้หน้าที่ของมัน

นักพัฒนาและทีม IT

1. แยกพื้นที่ทดลองก่อนเพิ่มรุ่น Ruff ใช้ branch หรือพื้นที่แยกการเปลี่ยนโค้ดของโครงการ แล้วรัน ruff check เปรียบเทียบผลเดิมกับผลใหม่ คำแนะนำนี้อิงรายการ breaking changes ซึ่งหมายถึงการเปลี่ยนที่อาจกระทบวิธีใช้เดิม ให้บันทึกว่าผลต่างมาจากกฎใดก่อนยอมรับ
2. ระบุรุ่นภาษาและกฎที่ทีมต้องการ ตั้ง target-version หรือ requires-python ให้ตรงกับสิ่งที่รองรับจริง จากนั้นทบทวนกฎวันเวลาในชุดเริ่มต้นที่ประกาศ เปลี่ยน ได้แก่ DTZ001, DTZ005, DTZ006, DTZ007, DTZ011, DTZ012 และ DTZ901 อย่าใช้เพียงจำนวนคำเตือนเป็นหลักฐานว่าเกณฑ์ทีมยังเหมือนเดิม
3. ย้ายค่าตั้งส่วนเสริมอย่างมีรายการตรวจ คู่มือ Astral ระบุว่า lint.run ไม่เกี่ยวข้องกับระบบใหม่ เพราะตรวจทุกครั้งที่พิมพ์เป็นค่าเริ่มต้น ส่วน lint.args และ format.args ถูกแทนด้วยค่าละเอียดกว่า เช่น lint.select และ configuration ให้จับคู่ความต้องการเดิมกับค่าใหม่ แทนการเก็บชื่อค่าที่ถูกเลิกใช้ไว้เฉย ๆ
4. ลบค่าที่ไม่รองรับและตรวจช่องทางติดตั้ง คู่มือ ให้ลบ ignoreStandardLibrary และ showNotifications จากการตั้งค่าที่ไม่รองรับ ส่วนโครงการที่ใช้ conda-forge ควรสำรวจคำสั่งเดิมตามข้อจำกัดในประกาศ โดยแยกจากเครื่องที่ติดตั้งผ่านช่องทางอื่น
5. ตรวจไฟล์และผลจัดรูปแบบก่อนรวมงาน ทีมที่ใช้กฎอนุญาตตามผู้เผยแพร่ควรทบทวนขั้นตอนกับผู้ดูแลความปลอดภัยจากข้อมูลลายเซ็น พร้อมอ่านผลต่างของ imports ที่อาจถูกจัดใหม่ คำแนะนำคือแยกการเปลี่ยนรูปแบบออกจากการแก้พฤติกรรม เพื่อให้คนตรวจงานเห็นเหตุผลของแต่ละส่วน

ผมมองว่า…

ผมมองว่าอัปเดตครั้งนี้ ไม่ใช่แค่เครื่องมือตรวจโค้ดมีลายเซ็น แต่คือทีมต้องทบทวนว่าไว้ใจไฟล์ไหนและใช้เกณฑ์ใดตรวจงาน ประโยชน์ของการรับรองผู้เผยแพร่ชัดเจนในประกาศ ส่วนภาระการย้ายค่าตั้งก็ชัดในคู่มือ การรับประโยชน์จึงควรมาพร้อมการอ่านผลตรวจ ไม่ใช่ถือว่ารุ่นใหม่แทนรุ่นเก่าได้โดยไม่มีสิ่งต้องเช็ก

ผมมองว่าคนเรียนไม่ควรต้องเดาเองว่าทำไมเครื่องตัวเองเตือนต่างจากเพื่อน ผู้สอนและทีมงานควรบอกเป้าหมายภาษา ช่องทางติดตั้ง และกฎที่ต้องใช้ร่วมกันให้ชัด ความเห็นนี้ไม่ได้อ้างว่าทุกห้องเรียนมีปัญหา แต่เป็นวิธีลดความสับสนจากการเปลี่ยนค่าเริ่มต้นที่ผู้พัฒนาระบุครับ

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่ควรประเมินหลังอัปเดตคือความสม่ำเสมอของขั้นตอนทำงาน ตั้งแต่รับไฟล์จนถึงอ่านผลตรวจ มากกว่าความใหม่ของเลขรุ่นเพียงอย่างเดียว จับตาว่าการเตือนผิดพลาดลดลงจริงในเครื่องของคุณหรือไม่ตามความคาดหมายของAstral และค่าตั้งส่วนเสริมถูกย้ายครบตามคู่มือ หรือยัง แหล่งข้อมูลที่อ่านไม่มีวันนัดหมายของการเปลี่ยนครั้งถัดไปครับ

ในโครงการหรือบทเรียนที่คุณใช้ ใครเป็นคนกำหนดรุ่น Python และกฎ Ruff ให้ทุกเครื่องตรงกัน?

Recap

• เกิดอะไรขึ้น: Ruff เพิ่มลายเซ็นรับรองไฟล์บน macOS และ Windows พร้อมเปลี่ยนเกณฑ์ตรวจ ตามประกาศรุ่น
• ตัวเลขที่จำ: Python 3.11 แปลว่าเป้าหมายเริ่มต้นใหม่เมื่อโครงการไม่ได้กำหนดรุ่น ตามประกาศ
• แยกเกณฑ์ตรวจไวยากรณ์: Python 3.15 แปลว่าค่าเริ่มต้นของการตรวจส่วนนี้เมื่อไม่ระบุรุ่น ตามแหล่งเดียวกัน
• ใครเห็นต่าง: ไม่มีเสียงค้านอิสระในแหล่งที่อ่าน ประกาศเน้นประโยชน์ ส่วนคู่มือ Astral ชี้งานย้ายค่าตั้ง ไม่พบข้อมูลขัดกัน
• ยังไม่รู้: ไม่มีผลวัดการเตือนผิดพลาดหรือเงินที่ทีมไทยประหยัดได้ และยังไม่ได้ทดสอบกับโครงการของเรา
• ผลต่อคุณ: เช็กเป้าหมายภาษา กฎตรวจ ค่าตั้ง VS Code และคำสั่งใน conda-forge ก่อนรวมการอัปเดต
• สิ่งที่จับตา: คำเตือนของเครื่องจริงและความตรงกันของผลตรวจหลังย้ายระบบ โดยยังไม่มีวันเปลี่ยนครั้งถัดไปในข้อมูลที่อ่าน
• แหล่งอ้างอิง: 1 — GitHub: ประกาศ Ruff และ 2 — Astral Docs: คู่มือย้ายระบบ