uv ตัวจัดการแพ็กเกจและโปรเจกต์ Python ที่เร็วมาก เขียนด้วย Rust

• uv เป็นเครื่องมือจัดการแพ็กเกจและโปรเจกต์ Python ที่สร้างด้วย Rust และมีความเร็วสูงมาก
• สามารถใช้แทน pip, pip-tools, pipx, poetry, pyenv, virtualenv และอื่น ๆ ได้ในเครื่องมือเดียว
• ให้ประสิทธิภาพสูงสุด เร็วกว่า 10–100 เท่า พร้อมช่วยประหยัดพื้นที่ดิสก์ มีแคชที่ทรงพลัง และรองรับการใช้งานแบบ cross-platform
• มีความสามารถรองรับสภาพแวดล้อมการพัฒนาแบบครบวงจร เช่น สคริปต์, โปรเจกต์, เครื่องมือ, และการจัดการ Python หลายเวอร์ชัน
• ช่วยให้สร้างเวิร์กโฟลว์การพัฒนา Python สมัยใหม่ที่เหมาะกับงานเพิ่มประสิทธิภาพการพัฒนา โปรเจกต์ขนาดใหญ่ และการทำงานที่ต้องการความเร็วสูง

---

แนะนำโอเพนซอร์สและจุดเด่นที่แตกต่าง

• uv รวมความสามารถของเครื่องมือจัดการ Python หลายตัว เช่น pip, pip-tools, pipx, poetry, pyenv, virtualenv, twine ไว้ใน เครื่องมือเดียว
• พัฒนาด้วย Rust จึงมี ประสิทธิภาพสูงมาก และมีความเร็วในการติดตั้งและซิงก์ เร็วกว่าระหว่าง 10–100 เท่า เมื่อเทียบกับ pip แบบดั้งเดิม
• มี global cache และการตัดความซ้ำซ้อนของ dependency เพื่อ เพิ่มประสิทธิภาพการใช้ดิสก์ พร้อมรองรับ CLI ที่ใช้งานง่าย และความเข้ากันได้กับ pip ที่คุ้นเคย
• ติดตั้งได้เป็นไฟล์รันเดี่ยวบนหลายแพลตฟอร์ม เช่น macOS, Linux, Windows
• จุดเด่นคือความสะดวกในการใช้งาน เช่น การติดตั้งแบบ standalone, การทำงานร่วมกับ pip และ pipx, และการอัปเดตอัตโนมัติในตัว

คุณสมบัติหลัก (Highlights)

• ใช้ uv ตัวเดียวแทนความสามารถหลากหลายของ pip, pip-tools, pipx, poetry, pyenv, twine, virtualenv และอื่น ๆ ได้
• ให้ประสิทธิภาพการติดตั้ง/อัปเดต/ซิงก์ เร็วกว่า pip เดิม 10–100 เท่า
• รองรับการจัดการ dependency ของโปรเจกต์บนพื้นฐาน lockfile รวมถึง workspaces และ universal lockfile
• รองรับการประกาศ dependency แบบ inline ในสคริปต์ และการรันแบบแยกสภาพแวดล้อมอัตโนมัติ
• รองรับการ จัดการ/ติดตั้ง/สลับ Python หลายเวอร์ชัน
• รองรับการ ติดตั้งและรันเครื่องมือ ที่แจกจ่ายในรูปแบบแพ็กเกจ Python (แทน pipx)
• เข้ากันได้กับอินเทอร์เฟซของ pip และมีความสามารถเพิ่มเติม เช่น การ override เวอร์ชัน และการแก้ dependency แบบไม่ผูกกับแพลตฟอร์ม
• มี workspace สไตล์ Cargo ที่เหมาะกับโปรเจกต์ขนาดใหญ่
• ใช้ global cache เพื่อลดความซ้ำซ้อนของ dependency และเพิ่มประสิทธิภาพการใช้พื้นที่ดิสก์
• ติดตั้งและใช้งานได้ผ่าน curl หรือ pip, pipx แม้ไม่มีสภาพแวดล้อม Rust/Python
• รองรับหลายแพลตฟอร์ม เช่น macOS, Linux, Windows
• พัฒนาโดยทีมเดียวกับที่สร้าง Astral และ Ruff

การจัดการโปรเจกต์ (Project Management)

• รองรับ dependency, environment, lock file, workspace ในระดับโปรเจกต์อย่างครบถ้วน
• ใช้คำสั่ง uv init เพื่อเริ่มต้นโปรเจกต์อัตโนมัติและสร้าง virtualenv
• ใช้ uv add เพื่อเพิ่ม dependency และใช้ uv lock กับ uv sync เพื่อซิงก์แพ็กเกจและตรวจสอบความปลอดภัยโดยอัตโนมัติ
• สามารถแทนความสามารถของเครื่องมือจัดการโปรเจกต์ Python สมัยใหม่อย่าง Poetry และ Rye พร้อมรับประกัน ความเร็วในการประมวลผลที่สูงกว่า
• รองรับการ build และ publish โปรเจกต์ที่ไม่ได้จัดการด้วย uv ด้วยเช่นกัน

การจัดการสคริปต์ (Scripts)

• สามารถประกาศ inline metadata ของ dependency ในสคริปต์ไฟล์เดียวได้
• เมื่อรันสคริปต์จะรองรับการ แยก virtual environment อัตโนมัติและติดตั้ง dependency
• ใช้ uv add --script เพื่อจัดการ dependency แยกตามสคริปต์ และใช้คำสั่ง uv run เพื่อรันแบบแยกสภาพแวดล้อม
• เหมาะอย่างยิ่งกับสคริปต์ใช้งานครั้งเดียว เช่น งาน data science หรือ automation

การจัดการเครื่องมือ (Tools)

• สามารถ ติดตั้งและรันเครื่องมือ CLI ที่อยู่ในรูปแบบแพ็กเกจ Python ได้เหมือน pipx
• ใช้ uv tool install, uvx เพื่อรันใน environment ชั่วคราวหรือแบบ global
• รองรับการตรวจสอบเครื่องมือที่ติดตั้งไว้ การจัดการเวอร์ชัน และการอัปเดต

การจัดการเวอร์ชัน Python

• สามารถ ติดตั้งและสลับ Python หลายเวอร์ชันได้ทันที อย่างง่ายดาย
• จัดการหลายเวอร์ชันแบบขนานได้ และกำหนด pin รายโปรเจกต์ผ่าน .python-version ได้
• รองรับ implementation ทางเลือกอย่าง pypy ผ่านอินเทอร์เฟซเดียวกัน
• ใช้คำสั่ง uv python install/pin เพื่อใช้ติดตั้ง ระบุ และเปิดใช้งานเวอร์ชัน

อินเทอร์เฟซ pip (Pip Interface)

• uv pip, uv venv สามารถใช้แทน pip, pip-tools, virtualenv แบบเดิมได้ อย่างสมบูรณ์
• มี ความสามารถขั้นสูง เช่น การ override เวอร์ชันของ dependency, การแก้ dependency แบบไม่ขึ้นกับแพลตฟอร์ม, และการ build ที่ทำซ้ำได้
• ใช้แทน pip แบบ drop-in ได้โดยไม่ต้องเปลี่ยนเวิร์กโฟลว์เดิม พร้อมให้ประสิทธิภาพ ดีขึ้น 10–100 เท่า
• รองรับการแปลง requirements.in → requirements.txt, การสร้าง virtual environment และการซิงก์ requirements

แพลตฟอร์มและนโยบายเวอร์ชัน

• รองรับระบบปฏิบัติการหลากหลาย (Windows, macOS, Linux)
• สามารถดูข้อมูลนโยบายและแพลตฟอร์มที่รองรับได้จากเอกสารทางการ

การมีส่วนร่วม (Contributing)

• มุ่งสนับสนุนผู้มีส่วนร่วมหลากหลายระดับตั้งแต่มือใหม่ถึงผู้เชี่ยวชาญ พร้อมมีคู่มือที่เกี่ยวข้องให้

FAQ

• uv ออกเสียงว่า “ยู-วี”
• รูปแบบการเขียนใช้ตัวพิมพ์เล็ก “uv” เท่านั้น

พื้นหลังทางเทคนิคและคำขอบคุณ (Acknowledgements)

• อัลกอริทึมการแก้ dependency ใช้ PubGrub
• การใช้งาน Git อิงจาก Cargo
• กลยุทธ์การปรับแต่งประสิทธิภาพได้รับแรงบันดาลใจอย่างมากจากเครื่องมือแพ็กเกจสมัยใหม่ เช่น pnpm, Orogene, Bun, Posy

ใบอนุญาต

• สามารถเลือกใช้ได้ระหว่าง MIT และ Apache-2.0
• โค้ดที่มีการร่วมพัฒนาก็อยู่ภายใต้เงื่อนไข dual license เดียวกัน

[GN⁺]

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

• เมื่อไม่กี่เดือนก่อนยังคิดว่าจะไม่มีวันใช้ uv เพราะคุ้นกับ venv และ pip อยู่แล้ว และไม่คิดว่าจำเป็นต้องมีเครื่องมืออื่น แต่เมื่อไม่นานมานี้ได้เจอสถานการณ์บนเซิร์ฟเวอร์ที่ใช้ร่วมกันซึ่งไม่มีสิทธิ์ root แพ็กเกจและไดรเวอร์ต่าง ๆ พังไปหมด แถมยังต้องใช้ pytorch พอดี เลยเปลี่ยนมาใช้ uv แบบเต็มตัว, pip ใช้เวลานาน แคชก็กินพื้นที่มากและย้ายตำแหน่งได้ไม่ค่อยดี พอเปลี่ยนมาใช้ uv ทุกอย่างกลับทำงานได้ดีมากจนพอใจมาก ถ้ายังลังเลอยู่ แนะนำให้ลองสัก 5 นาทีก็ยังดี

  • ข้อดีที่สุดของ uv คือมันเข้ากันได้เต็มที่กับเวิร์กโฟลว์แบบ venv ที่ใช้อยู่เดิม แค่รัน uv venv ก็จบ
  • uv รู้สึกว่าอธิบายได้ง่ายกว่าเยอะ โดยเฉพาะเวลาสอนผู้เริ่มต้นให้ใช้งาน, ชุด pip + ไฟล์ตั้งค่า + venv มักทำให้สับสนทั้งเรื่องการสร้าง venv ที่ถูกต้อง การติดตั้ง หรือการต้องจำ shebang แปลก ๆ และการ activate venv ทุกครั้งก่อนรันสคริปต์/ทดสอบ แถมข้อความ error ก็ช่วยได้ไม่เต็มที่ ตอนสอนมือใหม่เลยรู้สึกว่าเครื่องมือมันยุ่งยากมาก แต่ตอนนี้แค่จำ "uv run", "uv add", "uv sync" ก็พอ ทำให้เพื่อนร่วมทีมรับไปใช้ได้แบบไม่กดดันมาก
  • ส่วนตัวเคยใช้ asdf แล้วค่อยย้ายไป mise เลยสงสัยว่าถ้าเทียบกับเครื่องมืออเนกประสงค์อย่าง uv จะเป็นอย่างไร
  • เห็นบอกว่าแคชของ pip กินพื้นที่มากและย้ายตำแหน่งไม่ได้ดี เลยสงสัยว่า uv จัดการพื้นที่เก็บแพ็กเกจได้ดีกว่าหรือไม่ และถ้าดีกว่า เป็นเพราะมันแชร์ข้อมูลได้เก่งกว่าหรือเปล่า
  • เมื่อเร็ว ๆ นี้ได้ลองรันจากไกด์สั้น ๆ ที่เริ่มด้วย "uv a b c" ในรีโพทดลอง, ดูเหมือนภายในจะมีอะไรซ้ำซ้อนพอสมควร แต่ในการใช้งานจริงบนโฮสต์มาตรฐาน GNU-Debian-Ubuntu ก็ไม่เจอปัญหาอะไร ทุกอย่างราบรื่นดีเลยพอใจมาก

• ตอนใช้ uv ครั้งแรก จำได้ว่าเร็วมากเมื่อเทียบกับ pip จนคิดว่าตัวเองพลาดอะไรไปหรือมันทำงานไม่ถูกต้องหรือเปล่า

  • บางครั้งติดตั้งแพ็กเกจใช้เวลาราว 200ms เลยรู้สึกหน่วงนิดเดียวระหว่างกด Enter กับตอนที่พรอมป์ต์กลับมา แต่ถ้าเป็น Poetry นี่ระดับเดินไปชงกาแฟกลับมายังทัน เห็นความต่างเรื่องความเร็วชัดมาก
  • ฉันก็รู้สึกเหมือนกัน มันลื่นมากจนเหมือนไม่ใช่ Python
  • เมื่อไม่นานมานี้ก็มีประสบการณ์คล้ายกัน และนั่นทำให้ย้ายมาใช้ uv เต็มตัว
  • ฉันก็สงสัยเหมือนกัน แต่พอลองแล้วก็พอใจมากจนกลับไปแบบเดิมไม่ได้

• คิดว่า uv กับ ruff เป็นตัวอย่างโต้แย้งที่ยอดเยี่ยมของคำพูดที่ว่า "อย่าสร้างล้อขึ้นมาใหม่" เพราะถ้าเป้าหมายชัดเจน บางครั้งผลลัพธ์ก็ออกมาดีกว่าของเดิมอย่างมาก

  • โดยมากคำพูดแบบนั้นใช้ได้ในบริบทที่กำลังเตือนมือใหม่ที่ยังไม่เข้าใจของเดิมดีพอ กล่าวคือ มันจริงเฉพาะเวลาคนที่ไม่รู้ข้อจำกัดและจุดที่ควรปรับปรุงของระบบไปพยายามประดิษฐ์ใหม่แบบผลีผลาม สำหรับผู้เชี่ยวชาญจริง ๆ มันไม่ค่อยเกี่ยว
  • ไม่ใช่ว่าพวกเขาสร้างล้อขึ้นมาใหม่ แต่เป็นการเปลี่ยนล้อไม้เดิมให้เป็นวัสดุที่แข็งแรงกว่าและหมุนได้เร็วขึ้น 10 เท่า
  • แค่ดูประวัติศาสตร์ของการจัดการแพ็กเกจ Python ก็ให้ความรู้สึกว่าทุกคนกระโจนเข้ามาด้วยความคิดว่าจะทำให้ดีกว่าของเดิม
  • จริง ๆ แล้วสุภาษิต "อย่าสร้างล้อขึ้นมาใหม่" เองก็ไม่สมเหตุสมผล เพราะแม้แต่ล้อจริง ๆ เรายังพัฒนาอยู่เรื่อย ๆ และในซอฟต์แวร์ก็ไม่มีเหตุผลที่จะไม่สร้างล้อที่ดีกว่า
  • นอกเรื่องนิดหน่อย แต่ก็สงสัยว่าทำไมคนถึงชอบใช้คำยาวอย่าง "order of magnitude better" แทนที่จะใช้คำสั้น ๆ อย่าง "10x"

• บนระบบเล็ก ๆ/สเปกต่ำ (อย่าง AWS T2.micro ที่รัน Windows) uv จะพยายามดาวน์โหลดพร้อมกันมากเกินไปจน timeout, แก้ได้ด้วยการจำกัดจำนวนดาวน์โหลดพร้อมกันไว้ที่ 1~2 ผ่านตัวแปรแวดล้อม UV_CONCURRENT_DOWNLOADS, รู้สึกว่าค่าเริ่มต้นของ uv ดุดันเกินไป และคงดีถ้ามันปรับตามเซิร์ฟเวอร์อัตโนมัติโดยใช้ความเร็วดาวน์โหลดมาเป็นตัวช่วย

  • นี่ไม่ใช่เคสแปลกเลย ผู้ใช้จำนวนมากทำ side project บน VPS ราคาถูก, (ฉันเองก็ทำบ่อย แม้ไม่ใช่ AWS), ขอบคุณที่แชร์และหวังว่าการตรวจจับอัตโนมัติจะดีขึ้น

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

• ชอบคำสั่ง uv add <mydependencies> --script mycoolscript.py มาก และถ้าใส่ #!/usr/bin/env -S uv run ไว้ด้านบน ก็จะรันสคริปต์ Python ได้ทันที เลยเป็นเครื่องมือที่มีประโยชน์มาก

  • สามารถสอนวิธีนี้ให้ Claude Project ด้วยพรอมป์ต์ที่ปรับให้เฉพาะทาง ทำให้มันสร้างทั้งสคริปต์พร้อม dependency ได้อัตโนมัติจากอินพุตครั้งเดียว, cutoff ของ Claude 4 คือเดือนมีนาคม 2025, และใน Claude Sonnet 4 ฟีเจอร์นี้ทำงานได้แม้ไม่ต้องมีพรอมป์ต์เพิ่ม ตัวอย่างเช่น ถ้าใส่ URL มันจะสร้างโค้ดที่ใช้ httpx กับ beautifulsoup เพื่อ crawl แล้วคืนรายการลิงก์เป็น CSV ได้ทันที ข้อมูลที่เกี่ยวข้อง ผลลัพธ์สคริปต์จาก Claude
  • ใช้ทริกนี้ร่วมกับ app-mode ของโน้ตบุ๊ก Marimo.io, ถ้าติดตั้งแค่ uv ก็สามารถส่งต่อแอปที่โต้ตอบได้และทำซ้ำผลลัพธ์ได้ให้คนอื่นแบบเฉพาะหน้าและแทบไม่ต้องเตรียมอะไรเลย เป็นคู่ผสมที่ยอดเยี่ยมมาก
  • ตอนนี้กลายเป็นมีนิสัยรันสคริปต์เล็ก ๆ แบบสด ๆ ทันที เพราะไม่ต้องกังวลเรื่องสภาพแวดล้อมหรือการจัดการ dependency แล้ว ทำงานได้สบายขึ้นมาก, บทความ the little scripter, วิดีโอ YouTube ที่เกี่ยวข้อง, ez-mcp บน GitHub
  • ขอแก้ไขว่าตัวอย่างที่อ่านไปก่อนหน้านี้ตีความผิด และในบริบทของโปรเจกต์ uv add --script กับ uv add ธรรมดานั้นต่างกัน, อีกทั้งในเอกสารทางการยังมีฟีเจอร์ที่มีประโยชน์กว่าอีกมาก เช่น run --with หรือการรองรับ PEP723 แนะนำให้ลองดู ไกด์ทางการ
  • มีคำถามว่า "mydependencies" คืออะไรแบบเจาะจง หมายถึงไฟล์ตั้งค่าหรือเปล่า

• เคยลอง uv เมื่อก่อน และทึ่งมากที่มันทั้งเร็วมากและใช้งานง่าย ตอนนี้แทบไม่มีเหตุผลจะใช้ pip อีกแล้ว และถ้าใช้แค่ Python ก็ไม่จำเป็นต้องใช้ conda ด้วย

  • ตอนนี้ก็เลิกใช้ pyenv กับ poetry แล้วเหมือนกัน

• ชอบ UV มาก และก็ชอบ Ruff ของทีม Astral ด้วย เลยย้ายทั้งงาน linting/formatting จาก pylint + Black มาเป็น Ruff, เคยลดเวลา lint จาก 90 วินาทีเหลือต่ำกว่า 1.5 วินาที ทำเอาตกใจมาก

  • แต่ภายหลังพบว่า ruff ตรวจเช็กได้เพียงบางส่วนของ pylint และยังปล่อยผ่าน error ที่ชัดมากเกินไปบางอย่างไปด้วยซ้ำ, (เช่นโค้ดที่รันไม่ได้ก็ยังไม่โดนจับ)

• ช่วงนี้ชอบใช้แพตเทิร์นด้านล่างสำหรับรันสคริปต์ executable ขนาดเล็ก และใช้อยู่บ่อย ๆ

  #!/usr/bin/env -S uv --quiet run --script
  # /// script
  # requires-python = ">=3.13"
  # dependencies = [
  #   "python-dateutil",
  # ]
  # ///
  #
  # [python script that needs dateutil]  
  

  • บรรทัด shebang นี้จำยากเกินไป อยากให้มีรูปแบบที่ง่ายกว่านี้อย่าง #!/usr/bin/env uvx จะได้ไม่ต้องค้นหาทุกครั้งเวลาใช้งาน

• พอใจมากจนไม่อยากกลับไปใช้ pip/twine/requirements.txt อีกแล้ว หลายโปรเจกต์เคยเก็บ wheel ที่ใช้ร่วมกันไว้ใน GitLab ภายในองค์กร แต่ตอนนี้ YAML เดิม 10 บรรทัดแทนได้ด้วย uv build และ uv publish แค่สองบรรทัด, ดึง dependency ก็สะดวก และยังมองเห็น dependency หลักได้ในที่เดียว ไม่ต้องเอาทุกอย่างไปปนกันไว้ใน requirements.txt อีกต่อไป