Rye: ประสบการณ์ Python แบบไร้ความยุ่งยาก

 (rye.astral.sh)
2 คะแนน โดย GN⁺ 2024-07-10 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Rye เป็นเครื่องมือจัดการโปรเจ็กต์และแพ็กเกจที่ตั้งใจให้ดูแลการติดตั้ง Python, โปรเจ็กต์ pyproject.toml, การพึ่งพา, virtualenv และการติดตั้งเครื่องมือแบบ global ได้ในที่เดียว
  • ปัจจุบัน หยุดพัฒนาแล้ว และแนะนำให้ใช้โปรเจ็กต์สืบทอด uv ที่สร้างโดยผู้ดูแลชุดเดียวกัน
  • ผู้ใช้เดิมสามารถย้ายไปได้โดยอ้างอิง uv migration guide และแม้ Rye จะยังดาวน์โหลดได้ แต่ไม่มีแผนอัปเดตเพิ่มเติมอีกแล้ว
  • การหยุดอัปเดตรวมถึง การอัปเดตด้านความปลอดภัย ด้วย ดังนั้นสำหรับโปรเจ็กต์ใหม่หรือสภาพแวดล้อมที่ต้องดูแลระยะยาว ควรพิจารณาย้ายไปใช้ uv
  • ประสบการณ์ Python แบบครบวงจรที่ Rye ตั้งเป้าไว้ครอบคลุมถึงโปรเจ็กต์ที่ซับซ้อนและ monorepo แต่จุดศูนย์กลางของการบำรุงรักษาได้ย้ายไปอยู่ที่ uv

สถานะปัจจุบันของ Rye

  • หยุดพัฒนาและแนะนำ uv

    • แนะนำให้ผู้ใช้ทุกคนใช้ uv
    • uv เป็นโปรเจ็กต์สืบทอด ที่สร้างโดยผู้ดูแลชุดเดียวกัน
    • uv ได้รับการดูแลอย่างต่อเนื่องและถูกใช้งานอย่างแพร่หลายกว่า Rye มาก
    • ผู้ใช้ Rye เดิมสามารถดู uv migration guide ได้
    • ยังสามารถใช้ Rye ต่อได้ แต่ไม่มีแผนอัปเดตเพิ่มเติม
    • ไม่มีแผนสำหรับการอัปเดตด้านความปลอดภัยเช่นกัน

ความสามารถที่ Rye เคยมอบให้

  • Rye เป็น โซลูชันจัดการโปรเจ็กต์และแพ็กเกจ สำหรับ Python
  • ถูกสร้างขึ้นโดยมีเป้าหมายเป็นเครื่องมือแบบ one-stop สำหรับผู้ใช้ Python
  • ภายในประสบการณ์แบบรวมศูนย์เดียว สามารถจัดการงานต่อไปนี้ได้
    • การจัดการการติดตั้ง Python
    • การจัดการโปรเจ็กต์บนพื้นฐาน pyproject.toml
    • การจัดการการพึ่งพา
    • การจัดการ virtualenv
    • การติดตั้งเครื่องมือแบบ global
  • ออกแบบมาให้รองรับโปรเจ็กต์ที่ซับซ้อนและ monorepo
  • ดูวิดีโอแนะนำได้ที่ Watch an introduction

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

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

 
lum7671 2024-07-11

ผมใช้ Introduction - PDM
อยู่แล้ว หลังจากลองใช้นู่นนี่มาสักพัก

คงต้องลองใช้ Rye ดูบ้างแล้วครับ
 
GN⁺ 2024-07-10
ความคิดเห็นบน Hacker News

  • งานพัฒนาแพ็กเกจจิงหลักส่วนใหญ่ตอนนี้กำลังดำเนินอยู่ที่ uv และ Rye ใช้ uv ภายใน ดังนั้นเมื่อ uv ดีขึ้น Rye ก็จะดีขึ้นตามไปด้วย
    ตัวอย่างเช่น เมื่อเร็ว ๆ นี้ uv ได้เพิ่ม การแก้ dependency แบบครอบคลุมทุกแพลตฟอร์ม ทำให้สามารถสร้าง requirements.txt ที่ล็อกไว้ด้วยผลลัพธ์การแก้ dependency ชุดเดียวที่ทำงานได้บนทุกแพลตฟอร์มและทุกระบบปฏิบัติการ ไม่ใช่แค่ระบบที่กำลังรันอยู่ในขณะนั้น และ Rye เวอร์ชันล่าสุดก็รองรับสิ่งนี้แล้ว
    https://github.com/astral-sh/uv
    ผมกำลังพัฒนา Rye และ uv อยู่ ถ้ามีคำถามก็ยินดีตอบ

    • อยากรู้ว่า การแก้ dependency แบบครอบคลุมทุกแพลตฟอร์ม ของ Rye/UV ทำงานกับ PyTorch ได้ถูกต้องหรือไม่ หรือจะเจอปัญหาแบบเดียวกับ Poetry
      https://github.com/python-poetry/poetry/issues/6409
      https://news.ycombinator.com/item?id=39257501
    • อยากรู้ว่ามีงานหรือแผนสำหรับ lock file ข้ามแพลตฟอร์ม ให้ติดตามได้หรือไม่
      หนึ่งในเหตุผลที่ทีมของผมยังลังเลจะย้ายก็เพราะส่วนนี้ เราทำงานด้าน ML ดังนั้นถ้ายกโปรเจกต์ที่ใช้ PyTorch เป็นตัวอย่าง สถานะที่ต้องการคือใส่ dependency ทั้งหมดไว้ใน pyproject.toml แล้วสร้าง lock file สำหรับการตั้งค่าแพลตฟอร์มต่อไปนี้จากเครื่อง AArch64 Mac หรือเวิร์กสเตชัน AMD64 Windows ได้: Mac ที่ใช้ MPS PyTorch พื้นฐาน, Windows ที่ใช้ CUDA PyTorch, AArch64 Linux ที่ใช้ CPU PyTorch, AMD64 Linux ที่ใช้ CPU PyTorch, AMD64 Linux ที่ใช้ CUDA PyTorch
      ขอบคุณที่สร้าง Ruff ขึ้นมา ผมพอใจมากทั้งเรื่อง linting และ formatting
    • เป็นผลงานที่ยอดเยี่ยม เมื่อก่อนผมต้องตั้งค่าสภาพแวดล้อมทำงานของโปรเจกต์บนคอมพิวเตอร์เครื่องใหม่เป็นครั้งคราว และ pyenv+venv+pip ก็ทรมานเสมอ แต่ตอนนี้ย้ายมาใช้ Rye แล้ว
      ตอนนี้แค่ติดตั้ง Rye, ดึงจาก GitHub, พิมพ์ rye sync ก็จบ
    • ถ้าดูแลทั้ง uv และ rye อยู่ ก็สงสัยว่าทำไมถึงยังดูแลทั้งสองตัวพร้อมกัน เพื่อหลีกเลี่ยงความสับสนจาก การแตกแยกและภาระในการเลือก ผมคิดว่าปิด rye ตอนนี้น่าจะดีกว่าไหม
    • มีบริษัทจำนวนมากที่ให้ความสำคัญกับบิลด์ที่คาดการณ์ได้และมีประสิทธิภาพกำลังย้ายมาใช้ และในกระบวนการนั้นมักต้อง สร้าง SBOM เพื่อนำเข้าเครื่องมืออย่าง guac
      https://guac.sh/
      https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
      ฟีเจอร์เลิกตรึง dependency ที่เพิ่งเพิ่มเข้ามาช่วยชี้นำให้รักษาความเข้ากันได้ระหว่างการพัฒนา และสามารถสร้าง requirements.txt ที่ถูกต้องชัดเจนเพื่อความสามารถในการทำซ้ำได้ ทำให้ขั้นตอนการจัดการช่องโหว่และ SBOM ง่ายกว่าเครื่องมืออย่าง Poetry มาก
      ด้วยเหตุผลคล้ายกัน ผมจึงใช้ https://hatch.pypa.io/latest/why/ อยู่ และชอบที่มันเข้ากันได้ดีกับ uv

  • สิ่งที่ทำให้ลังเลกับ Rye คือส่วนที่แนะนำอย่างหนักให้ใช้ Python build ที่ไม่ใช่มาตรฐาน
    ในหน้าปรัชญา (https://rye.astral.sh/philosophy/) อธิบายว่า build ของ CPython จาก python.org ไม่เหมาะสมอย่างสิ้นเชิง บางแพลตฟอร์มมีแค่ไฟล์ติดตั้ง .msi หรือมีแค่ tarball และ Python distribution หลายตัวก็แตกต่างกันมากจนสร้างปัญหาสารพัดให้กับ ecosystem ย่อย ดังนั้นโปรเจกต์นี้จึงใช้ build แบบ standalone ของ indygreg และหวังว่าสักวันหนึ่งจะมี Python build ที่ดูแลดีและเชื่อถือได้ออกมาแทนที่ความสับสนในปัจจุบัน
    ข้อมูลของ build indygreg นั้นอยู่ที่ https://gregoryszorc.com/docs/python-build-standalone/main/ และยังเลือก Python ตัวอื่นได้ด้วย: https://rye.astral.sh/guide/toolchains/
    แต่ผมแทบไม่เคยเจอปัญหาที่พวกเขาพูดถึงเลย Python build ทางการที่ได้จาก python.org ก็ใช้งานได้, Python ธรรมดาที่ติดตั้งผ่าน package manager ของ distribution ก็ใช้งานได้, และ Python ที่มากับ image ของคอนเทนเนอร์ Docker ทางการก็ใช้งานได้
    build พิเศษเหล่านั้นก็คงใช้งานได้ดี แต่ผมลังเลเพราะ ความไม่เป็นมาตรฐาน ถึงขั้นมีรายการพฤติกรรมเฉพาะตัวด้วยซ้ำ ผมไม่เข้าใจว่าทำไมต้องเพิ่มความเฉพาะตัวให้กับสิ่งที่ไม่ได้มีปัญหา ปรัชญาของ Rye ที่ผลักดันให้ใช้ build นั้นอย่างมากก็ทำให้มันน่าสนใจน้อยลง เมื่อเทียบกับทางเลือกที่ใช้ Python ที่มีอยู่แล้วในระบบปฏิบัติการเป็นค่าเริ่มต้น

    • น่าจะหมายถึงสถานการณ์แบบนี้: ทำงานในบริษัทที่ใช้ของอย่าง CentOS เก่า ๆ, package manager ของระบบไม่มีอะไรใหม่กว่า Python 3.6 ให้ และไบนารีทางการจาก python.org พอรันแล้วก็พ่นข้อผิดพลาดอ่านไม่รู้เรื่องเกี่ยวกับ เวอร์ชัน glibc
      ถ้าจะ build Python จากซอร์ส ก็ต้องมี system dependency ใหม่ ๆ ใช้เวลานาน และสุดท้ายก็เจอข้อผิดพลาดที่ยิ่งไม่เข้าใจเกี่ยวกับไฟล์ header ที่หายไป พอค้นข้อผิดพลาดนั้นก็เจอ flag ของ ./configure ที่ใช้เลี่ยงปัญหาที่ upstream GCC แก้ไปแล้วตั้งแต่ปี 2017 และสุดท้ายก็สำเร็จอยู่ดี
      ถ้าไม่เคยเจอข้อผิดพลาดแบบนี้สัก 3 ครั้งหรือ สภาพแวดล้อม build ของ manylinux ก็แปลว่าคุณหลบเลี่ยงโลกแห่งความเจ็บปวดไปได้ทั้งใบแล้ว เรื่องสคริปต์ติดตั้งบน Windows หรือส่วนอย่าง “ข้อจำกัดของคำสั่ง CPU ที่ใช้งานได้” ในหน้านั้นก็เช่นกัน
    • การ build, packaging และ distribution ของ Python มีสองขั้วสุดโต่ง ขั้วหนึ่งคือ เส้นทางหลักที่ราบรื่น ส่วนอีกขั้วคือทางเดินที่มีคมมีดนับพันเล่ม ถ้าคุณไม่เข้าใจว่าทำไมถึงมีข้อเสนอ Python แบบพกพา ก็แปลว่าคุณโชคดี และยังคงอยู่บนเส้นทางหลักที่ราบรื่นมาตลอด

  • ดาวน์โหลดซอร์สโค้ด Python เป็นประจำ คอมไพล์ด้วยการปรับแต่งมาตรฐานสำหรับโปรดักชัน แล้วติดตั้งไว้ที่ /use/local/python${version} ซึ่งทำงานได้อย่างสม่ำเสมอมากตั้งแต่ Python 3.7 ออกมาในปี 2018
    จากประสบการณ์ของผม คำสั่งเหล่านี้เสถียรและสม่ำเสมอมากจนแทบจะเอาไปทำอัตโนมัติได้ เลยสงสัยว่าจุดที่ผู้เขียนมองว่าเป็นปัญหา หรือข้อคัดค้านพื้นฐานจริง ๆ คืออะไร

    • คำว่า “บิลด์ CPython ของ python.org ไม่เหมาะสมอย่างสิ้นเชิง” อาจหมายถึงการไม่มี ไบนารีสำหรับ macOS/Windows สำหรับรีลีสความปลอดภัยของ Python เวอร์ชันเก่า
      ตัวอย่างเช่น ไม่สามารถดาวน์โหลดไฟล์ติดตั้ง Python 3.10.14 ได้ และไฟล์ติดตั้ง Windows ตัวสุดท้ายคือ Python 3.10.11 เวอร์ชันวันที่ 5 เมษายน 2023
    • เห็นด้วย ควรสนับสนุน PSF มากกว่าจะยืนกรานเสนอ “วิธีที่ถูกต้อง” แบบใหม่ ซึ่งเป็นจุดยืนที่แปลก

  • ชอบ Rye มันทำสิ่งที่ประกาศไว้ได้ตรงตามนั้น ทำให้กระบวนการทั้งหมดของ venv/เวอร์ชัน Python/แพ็กเกจจิงใช้งานได้สบายขึ้นจริง และสำหรับคนที่คุ้นกับวิธีใช้งาน Python อย่างเป็นทางการอย่าง pyproject.toml ก็แทบจะรู้สึกโปร่งใสไม่สะดุด
    แถมยังทำให้ Python ให้ความรู้สึกเหมือน Cargo ซึ่ง Cargo เองก็เป็นเครื่องมือที่ใช้งานดี

    • ถ้าเคยเมินเครื่องมือสาย Poetry แบบผมและยังอยู่กับ pip-tools อยู่ uv ที่ Rye ใช้ภายในก็เป็นเครื่องมือที่แทนกันได้เลย
      ส่วนตัวมองว่า pip-tools มีการออกแบบที่ดีกว่า Poetry หรือ Pipenv มาก มันตั้งฉากกับทั้ง pip และ virtualenv และทั้งสองอย่างก็เป็นแนวทางที่อยู่กับ Python มานานแล้ว Rye จึงมองได้ว่าเป็นภาพของแนวทางที่สอดคล้องกับมาตรฐานและผ่านการปรับปรุงซ้ำ ๆ จนชนะ
      นอกจากความเร็วที่ได้จาก Rust แล้ว ยังชอบที่มันให้ค่าเริ่มต้นที่เหมาะสมเรื่องจะวาง virtual environment ไว้ที่ไหน (.venv) และจะติดตั้ง Python หลายเวอร์ชันอย่างไร ดูเหมือนเรื่องเล็ก แต่หลังจาก wheel แก้ปัญหาการติดตั้ง numpy ไปแล้ว ค่าเริ่มต้นที่สมเหตุสมผลแบบนี้กับ pip-tools ในตัวนี่แหละคือสิ่งที่ขาดอยู่แทบทั้งหมด ในแง่นั้นก็สงสัยเหมือนกันว่าหลังจากมี binary wheel แล้ว เหตุผลในการมีอยู่ของ Anaconda คืออะไรกันแน่
    • เริ่มลอง Python เพราะได้ยินว่ามีวิธีเดียวสำหรับทุกอย่าง แต่ประสบการณ์ด้าน การติดตั้งและการจัดการ environment กลับเละเทะมาก
      ดีใจที่อย่างน้อยตอนนี้มันกำลังดีขึ้น
    • ถ้าบอกว่า “ทำให้ Python ให้ความรู้สึกเหมือน Cargo” ก็โน้มน้าวได้ทันที ตอนนั้นกำลังคิดจะลอง pixi อยู่พอดี เพราะ Poetry ใช้เวลาทั้งวันแล้วยัง resolve dependency ไม่ได้
      ดูเหมือน package manager ของ Python จะมีมากกว่าแอปแชตของ Google เสียอีก
    • สงสัยว่า “ทำให้ใช้งานได้สบายจริง” หมายถึงอะไร มันยากเกินกว่าจะสรุปหรือเปล่า? ผมหาส่วนที่รู้สึกว่าเป็นตัวเลือกพิเศษด้านประสบการณ์ผู้ใช้ใน Anaconda หรือ Poetry ไม่ค่อยเจอ
      และในแง่การคัดสรร ข้อเสนอให้เชื่อใจองค์กรเล็กมากกว่าองค์กรที่ใหญ่กว่าและเก่ากว่าดูไม่น่าโน้มน้าวนัก กล่าวคืออยากรู้ว่าสิ่งที่ประกาศไว้นั้นคืออะไรกันแน่ เท่าที่อ่านได้ก็ประมาณว่า “package manager ที่ดีก็ดี เร็ว และดี” ถ้ามีหน้าที่เปรียบเทียบหรืออธิบายปรัชญาก็น่าจะดี

  • บางครั้งความประชดประชันบน HN ก็น่าทึ่ง
    ชอบ Rye หลังจากใช้ package manager ของภาษาอื่นอย่าง Cargo หรือ Hex แล้ว ผมรู้สึกเสียดายมาตลอดที่ Python ไม่มีระบบคล้ายกัน และ Rye ก็เติมเต็มความกระหายนั้นได้หมดจดจริง ๆ ในฐานะคนที่ไม่อยากติดตั้งหลายเครื่องมือเพื่อจัดการ venv, เวอร์ชัน Python และ dependency ของโปรเจกต์ การที่ Rye ตัวเดียวจัดการได้ทั้งหมด นั้นดีมาก

    • อยากรู้ว่าเคยลอง conda ไหม ถ้าเทียบกับ conda แล้ว Rye เป็นอย่างไร?
      ผมยังไม่ค่อยจับทาง Rye ได้ แต่ conda ก็จัดการ venv, เวอร์ชัน Python และ dependency ของโปรเจกต์ได้ดีเหมือนกัน
    • เห็นด้วย Rye ใช้งานได้ดีสำหรับผม ผมอยากได้ Cargo สำหรับ Python และจนถึงตอนนี้จากมุมมองของผม Rye ก็ทำสิ่งนั้นสำเร็จแล้ว

  • การเจอ dependency manager ตัวใหม่ของ Python ให้ความรู้สึกเหมือนบังเอิญเจอ JavaScript framework ตัวใหม่

    • ปรัชญาของผมเรียบง่าย ถ้าต้องเป็นโปรแกรมที่แจกจ่ายได้ก็ใช้ Go ไปเลย ถ้าไม่ต้องการอะไรอย่าง port ก็ใช้ Docker และถ้าทีม IT หรือใครสักคนส่งเครื่องที่ติดตั้งระบบปฏิบัติการกับเวอร์ชัน Python ที่ทุกคนในองค์กรใช้มาให้ ก็ใช้ venv
      ถ้าต้องจัดการ port หรือต้องแจกจ่ายโปรแกรม หรือไลบรารีพึ่งพา C หรือองค์ประกอบของระบบปฏิบัติการ การไปทำงานคอนซัลต์ที่รับเงินแล้วไม่ต้องดูแลโค้ดเบสหรือรับผิดชอบทีหลังน่าจะดีกว่า
    • ใช่แล้ว Docker แก้ปัญหาการแจกจ่ายและรันโปรแกรม Python ไปตั้งแต่ราว 10 ปีก่อนแล้ว
      ทุกวันนี้ยังรัน CUDA และ PyTorch ใน Docker ได้ด้วย ในเธรดแบบนี้ ถ้ามีคนบอกว่า “ก็ใช้ Docker สิ” คำตอบที่พบบ่อยคือ “ไม่อยากเรียน Docker” แต่ต่อให้ไม่มีประสบการณ์ Docker เลย การเปิดคอนเทนเนอร์ Python ใช้เวลาแค่ 10 นาที
    • ใช่ แต่ต่างจากพวก Poetry ครั้งนี้มันดีจริง
    • แย่มากจริง ๆ ในมุมผู้ใช้ มันน่าหงุดหงิดที่ผ่านมาหลายปีขนาดนี้แล้วยังไม่มี มาตรฐาน

  • pixi(https://pixi.sh/latest/) ดีมาก สามารถตรึงเวอร์ชัน Python และติดตั้งแพ็กเกจจาก conda กับ PyPI ได้ อีกทั้งเขียนด้วย Rust

    • ดูน่าสนใจ แต่รู้สึกยากที่จะลงทุนจริงจังกับ ecosystem อีกตัว การให้ดาวน์โหลดด้วย curl แล้ว pipe เข้า bash จากนั้นให้ eval เอาต์พุตคำสั่งตามอำเภอใจต่อ รู้สึกน่ากังวล
    • ขอบคุณสำหรับลิงก์ สงสัยว่าเร็วกว่า conda ไหม
    • pixi ยอดเยี่ยมมาก ถ้าเป็นคนใช้ conda อยู่ pixi ใช้แทน conda ได้ในแบบที่มี environment ผูกกับ Git/ไดเรกทอรีโปรเจกต์ คล้ายกับ devbox/devenv/flox
      ภูมิหลังค่อนข้างซับซ้อน เดิมบริษัท Anaconda มี conda ที่เขียนด้วย Python และ conda-forge ซึ่งเป็น ecosystem โอเพนซอร์สก็เป็น conda channel ที่มีบอทบิลด์ CI ต่อมาภายใต้ร่ม conda-forge เดียวกัน mamba ที่เขียนด้วย C++ ก็ออกมาเป็นตัวแทน conda และเป็น drop-in replacement จริงในระดับที่ alias conda=mamba ควรจะใช้งานได้ ตอนนี้ conda เองก็ใช้ libmamba เป็น resolver เพื่อเพิ่มความเร็วแล้ว
      หลังจากนั้นผู้เขียน mamba แยกมันออกมาเป็น pixi และเขียนใหม่ด้วย Rust พร้อมเปลี่ยนปรัชญาเรื่องตำแหน่งของ environment และวิธี activate แต่ยังเข้ากันได้เต็มที่กับ conda environment

conda รองรับการติดตั้งแพ็กเกจ PyPI ผ่าน pip มาโดยตลอดในกรณีที่ไม่มีอยู่ในช่อง conda และ pixi ก็รองรับแพ็กเกจ PyPI ผ่าน uv ดังนั้น pixi จึงเร็ว ตามบทความบล็อก ยังมีการปรับให้เหมาะสมอื่น ๆ ที่ทำให้เร็วกว่า mamba มากด้วย
ถ้าใช้แพ็กเกจที่ไม่ใช่ Python ล้วน ๆ สาย conda คือคำตอบ ส่วนการเลือกตัวจัดการแพ็กเกจ (conda/mamba/pixi) เป็นเรื่องรอง
ปัญหาของ PyPI คือขาดบทบาทผู้เฝ้าประตู อีกทั้งยังซ้อนกับปัญหาที่ขาดวิธีมาตรฐานในการแพ็กเกจสิ่งที่ไม่ใช่ Python ล้วน ๆ ทำให้สภาพแวดล้อมรั่วไหล หรือโดยเฉพาะถ้าแจกจ่ายแค่ซอร์ส แล้วทำเรื่องแปลก ๆ อย่างบูตสแตรปสภาพแวดล้อมใน setup.py ไปจนถึงคอมไพเลอร์ ก็จะทำให้ทำซ้ำไม่ได้
ฝั่ง conda นั้น ช่อง conda-forge มีการควบคุมคุณภาพค่อนข้างดี ตรวจสอบข้อกำหนดจำกัด ไลเซนส์ ปัญหาที่ไฟล์ไลเซนส์หายไปจากชุดเผยแพร่บน PyPI การแยกสภาพแวดล้อม ฯลฯ แน่นอนว่าไม่สมบูรณ์แบบ เพราะผู้ดูแลสามารถใช้บอตทางการที่ merge อัตโนมัติการเปลี่ยนแปลงจาก PyPI ที่มีข้อกำหนดเวอร์ชันผิดได้
ปัญหาที่ตอนนี้ไม่มีเครื่องมือไหนแก้ได้คือการมี PyPI เป็นศูนย์กลาง ต้องจัดการแพ็กเกจที่ไม่มีใน conda และการปล่อยแพ็กเกจก็แทบถูกบังคับให้ปล่อยบน PyPI ก่อน
แม้ตอนติดตั้งแพ็กเกจที่มีเฉพาะบน PyPI ผ่าน conda ก็เป็นไปได้ว่าบาง dependency ของแพ็กเกจนั้นมีอยู่ใน conda เท่าที่ผมรู้ ไม่มีตัวจัดการแพ็กเกจตัวไหนที่ใช้แพ็กเกจ conda เพื่อเติมเต็ม dependency ของแพ็กเกจ PyPI ได้ คุณสามารถเพิ่มแพ็กเกจ conda ด้วยมือเพื่อให้ dependency ครบได้ แต่มีความเสี่ยงว่าจะไม่ได้ใช้ข้อกำหนดเวอร์ชันที่ถูกต้อง
แม้ตอนเขียนแพ็กเกจ Python แบบโอเพนซอร์ส ถึงการตั้งค่าจะพึ่งพาเฉพาะช่อง conda ก็ตาม ส่วนใหญ่ก็ต้องหรือควรปล่อยบน PyPI ก่อนอยู่ดี เพราะการปล่อยบนช่อง conda-forge โดยพฤตินัยต้องการให้มีอยู่บน PyPI ดังนั้นสำหรับคนอย่างผม Rye ก็ยังอาจมีประโยชน์และควรค่าแก่การลองดู

  • น่ารู้ว่าคนฝั่ง uv (https://astral.sh/blog/uv) ได้รับไม้ต่อในการนำ โปรเจกต์ของ Armin นี้แล้ว
  • ในหน้าแนะนำเขียนไว้ว่า “Rye is still a very experimental tool, but this guide is here to help you get started.”
    ผมคาดหวังกับโปรเจกต์นี้มาก แต่ตั้งใจจะรอจนกว่าจะถึง ระยะที่เติบโตเต็มที่ มากกว่านี้ ผมชอบทุกอย่างที่ทีม Astral ทำออกมา จึงคาดหวังสูง
  • เราใช้ rye ในการพัฒนาไลบรารี openai-python และมันดีมาก
  • Rye ดูดี และผมก็ใช้ Poetry ได้ค่อนข้างสนุก แต่ทำให้ยิ่งเคารพ คุณภาพของเครื่องมือพื้นฐานของ Go จริง ๆ
    ทุกครั้งที่เริ่มโปรเจกต์ Python ผมรู้สึกเหมือนต้องเรียนรู้สถานะล่าสุดของการจัดการ dependency/virtual environment ใหม่อีกรอบ