เปิดตัว Homebrew 6.0.0

 (brew.sh)
3 คะแนน โดย GN⁺ 4 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Internal JSON API ที่รวมเมตาดาต้าทั้งหมดไว้ในการดาวน์โหลดครั้งเดียว ถูกเปลี่ยนให้เป็นค่าเริ่มต้น ช่วยให้การอัปเดตเร็วขึ้นและลดการสื่อสารผ่านเครือข่าย
    • ตัวแปร opt-in เดิม HOMEBREW_USE_INTERNAL_API ถูกประกาศเป็น deprecated
  • บน Linux มีการใช้ Bubblewrap sandbox ทำให้ขั้นตอน build·test·postinstall ทำงานแบบแยกสภาพแวดล้อมเช่นเดียวกับบน macOS
  • จากผลสำรวจผู้ใช้ โหมด ask ถูกเปลี่ยนเป็นค่าเริ่มต้นสำหรับนักพัฒนา โดยจะแสดงสรุป dependencies และพรอมป์ตยืนยันเมื่อใช้ brew install·brew upgrade
  • ใน brew bundle มีการเปิดใช้ การติดตั้ง formula แบบขนาน โดยอัตโนมัติเป็นค่าเริ่มต้น พร้อมเพิ่มการรองรับส่วนขยาย npm·krew และ winget บน Windows
  • มีการปรับปรุง ประสิทธิภาพ โดยรวม ทั้งการเริ่มต้นและการอัปเกรด เช่น brew leaves เร็วขึ้นประมาณ 30%
  • เพิ่มการรองรับเบื้องต้นสำหรับ macOS 27 (Golden Gate)
    • เนื่องจากยุติการรองรับ Intel, macOS Intel x86_64 จะถูกลดเป็น Tier 3 ในเดือนกันยายน 2026 และจะเลิกรองรับอย่างสมบูรณ์ในเดือนกันยายน 2027
  • เปิดเผยและแก้ไข คำแนะนำด้านความปลอดภัย 3 รายการ (การข้ามผ่าน HTTPS→HTTP redirect, การรัน root code ใน .pkg postinstall, การยึดครองสิทธิ์ความเป็นเจ้าของ plist ใน /var/tmp)
  • เพิ่มคำสั่งใหม่ เช่น brew exec ที่คล้าย npx และ brew vulns สำหรับตรวจสอบช่องโหว่ของแพ็กเกจที่ติดตั้งไว้
  • นำ install steps framework มาใช้ โดยเปิดเผยการทำงานร่วมกันของ postinstall·flight เป็นข้อมูล literal DSL ผ่าน JSON API ทำให้งานที่ไม่ซับซ้อนไม่จำเป็นต้องดาวน์โหลดและประมวลผลไฟล์ Ruby
  • ใช้ cooldown กับการดาวน์โหลดใน ecosystem ที่มีความเสี่ยง เช่น npm·PyPI เพื่อบรรเทาความเสี่ยงด้านความปลอดภัยฝั่ง upstream supply

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

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

 
lamanus 27 분 전

ทรัพยากรก็มีไม่พอสำหรับการรองรับไปจนถึง Intel Mac และ GitHub Actions เองก็มีแผนจะไม่ให้บริการอิมเมจอีกต่อไปแล้ว ดังนั้น Homebrew เองก็ไม่มีทางเลือกนอกจากต้องดำเนินไปในทิศทางนี้เช่นกัน
 
GN⁺ 4 시간 전
ความเห็นบน Hacker News

  • ผมคือ @bfontaine บน GitHub เคยช่วย ดูแล Homebrew ราว ๆ ปี 2014~2016 และก็ยังทึ่งเสมอที่ Mike ดูแลมันต่อเนื่องมาเกิน 16 ปีแล้วยังออกฟีเจอร์ใหม่ได้อยู่

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

  • ผมลองย้าย สภาพแวดล้อมการพัฒนาระดับ OS ทั้งหมดจาก Homebrew+pipx+npm ไปเป็น https://mise.jdx.dev/ แบบทดลองดู แล้วมันก็ทำงานได้ดีมากจริง ๆ
    เครื่องมือหลายตัวติดตั้งตรงจาก GitHub releases หรือจากตัวจัดการแพ็กเกจที่ตรงกับมันเอง (เช่น uv, pnpm, go get) จึงไม่มีโค้ดกาวสำหรับรีแพ็กเกจและไม่มีดีเลย์เรื่องเวอร์ชัน
    สามารถติดตั้งเวอร์ชันตามต้องการหรือหลายเวอร์ชันพร้อมกันได้ และสลับเวอร์ชันที่ใช้งานแบบไดนามิกตามโฟลเดอร์งานหรือสภาพแวดล้อมได้
    ที่น่าสนใจคือ Mise ไม่รองรับ dependency แบบเต็มตัว แต่ส่วนใหญ่ก็ไม่เป็นปัญหา เพราะ pnpm/uv จัดการให้ หรือไม่ก็เป็น static binary ที่ใช้งานได้เลย
    ก่อนหน้านี้ผมเคยแพ็กเกจแอป Python สำหรับ Homebrew โดยต้องดึง dependency 50 ตัวมาเป็น resources, สร้างทั้งหมดจากซอร์สหรือคอยเช็กเองว่ามีใน Homebrew หรือยัง, ประกาศ build toolchain จาก 5 ภาษาเป็น dependency และรอ CI เกินชั่วโมงทุกครั้งที่อัปเดต ก่อนจะเจอกรณีที่อัปเดตจาก upstream ทำให้เกิด “build-time dependency loop” จนแก้ใน Homebrew ไม่ได้
    เพราะแบบนั้นผมจึงเข้าใจเต็มที่ว่าทำไม Mise ถึงเลือก “ทางที่ง่ายกว่า” ด้วยการพึ่งตัวจัดการแพ็กเกจประจำภาษาโดยตรง
    สิ่งเดียวที่ผมแทนจาก Brewfile ไม่ได้คือ Docker CLI ที่ต้องใช้คุยกับ Colima และสำหรับ cask ก็ยังใช้ Homebrew อยู่ แนะนำให้ลองทดลองกับสภาพแวดล้อมการพัฒนาดู ทุกวันนี้มีเครื่องมือใหม่ดี ๆ เยอะมาก

    • Mise ดูเหมือนจะอยู่คนละระดับจริง ๆ อย่างที่ผมเคยพูดไว้ที่อื่น มันพึ่งรีจิสทรีอย่าง aqua หรือ asdf
      สำหรับคนที่อยากใช้ Mise กับแพ็กเกจของ Homebrew มี https://github.com/kennyg/mise-zerobrew
    • ในฐานะนักพัฒนา PHP ผมรู้สึกว่าการรองรับของ Mise ยังด้อยกว่า การแพ็กเกจ PHP ที่ Shivam Mathur ทำไว้ให้ Homebrew อยู่พอสมควร
      โปรเจกต์ส่วนใหญ่ยังไงก็ใช้ Docker อยู่แล้ว และ PHP บนเครื่องโลคัลก็มีไว้ใช้กับงานอย่าง static analysis ที่ไม่จำเป็นต้องใช้ Docker
      ผมก็มีบางโปรเจกต์ที่ใช้ Nix ซึ่ง Nix นั้นเก่งจนเหมือนหัวเราะเยาะทุกอย่างที่เหลือ แต่ประสบการณ์ใช้งานโดยรวมเป็นมิตรน้อยกว่าแม้แต่ git เสียอีก
    • ดีใจที่คุณมีประสบการณ์ที่ดี แต่ส่วนตัวผม ย้ายกลับจาก Mise มาใช้ Brew อีกครั้ง
      อาจเป็นเพราะความสามารถของผมเอง แต่มีแพ็กเกจเยอะเกินไปที่มีปัญหาบน Mise
    • ผมชอบ Mise มาก แต่ใช้แค่กับการจัดการเครื่องมือรายโปรเจกต์หรืออะไรอย่าง เวอร์ชัน JDK เท่านั้น
      ผมเคยลองใช้กับเครื่องมือระดับทั้งระบบเหมือนกัน แต่กับเครื่องมืออย่าง Helix, NeoVim, RipGrep ที่ขอแค่ค่อนข้างใหม่พอและไม่ได้สนใจเวอร์ชันเป๊ะ ๆ มันไม่ค่อยเหมาะนัก
    • Mise ก็รองรับ dependency ในระดับหนึ่ง แต่ไม่ใช่แบบที่คาดหวังจากตัวจัดการแพ็กเกจอื่น
      dependency ของ Mise ไม่ได้ทำอัตโนมัติ ต้องกำหนดเองทั้งหมด จุดประสงค์คือเพื่อหลีกเลี่ยงปัญหาเรื่องลำดับที่เกิดจากการติดตั้งแบบขนาน ตัวอย่างเช่น ถ้าใช้ pipx:black ก็ต้องรอให้ติดตั้ง Python เสร็จก่อน นี่คือสิ่งที่ตัวเลือก depends ของเครื่องมือใช้จัดการ
      นี่เป็นการออกแบบโดยตั้งใจ Mise ไม่ได้ถูกออกแบบให้เป็นคำตอบด้านการ bootstrap แบบสมบูรณ์เหมือน Homebrew หรือ Nix แต่เป็น overlay ที่วางอยู่บนระบบเดิม
      เพราะฉะนั้นคุณจะให้ Python จัดการด้วย Brew แล้วให้ black จัดการด้วย Mise ก็ยังทำงานได้แทบตรงไปตรงมาโดยไม่ต้องตั้งค่าเพิ่ม ผมมองว่าการตัดสินใจออกแบบนี้ประสบความสำเร็จมาก ถึงจะฟังเหมือนข้อเสีย แต่สุดท้ายอาจเป็นเหตุผลหลักที่ทำให้ผู้ใช้รู้สึกว่า Mise ใช้ง่าย

  • Homebrew เป็นวิธีที่ยอดเยี่ยมในการ bootstrap สภาพแวดล้อมอย่างรวดเร็วบน ดิสโทร Linux แบบ immutable
    แม้จำนวนผู้ใช้จะไม่มาก แต่ตาม https://formulae.brew.sh/analytics/os-version/365d/ ระบบปฏิบัติการอย่าง Bazzite (1.28%), Bluefin (0.49%), Aurora (0.28%) ของ Universal Blue ก็แถม Homebrew มาให้เป็นค่าเริ่มต้น
    รีโปที่เกี่ยวข้องคือ https://github.com/ublue-os/brew

    • แนวคิดเรื่อง ตัวจัดการแพ็กเกจใน user space ดูเหมือนเป็นสิ่งที่ Linux ควรแก้ได้ตั้งแต่ 20 ปีก่อนแล้ว
      มันตลกที่สถานการณ์ปกติของผู้ใช้ที่ไม่ใช่ root คือ “ติดตั้ง XY ไม่ได้ แต่ถ้าจะไปคอมไพล์จากซอร์สเองก็ตามสบาย”
      ตอนนี้ Homebrew, Mise และ Nix กำลังเข้ามาเติมช่องว่างนั้น ส่วน Flatpak จะใกล้กับฝั่งแอป GUI มากกว่า และ Snap ก็... มีอยู่แหละ
    • ผมใช้ Nix บน Bazzite ร่วมกับ home-manager

  • สามอย่างแรกที่ผมติดตั้งคือ Sublime Text, Homebrew และ Bash เวอร์ชันล่าสุด ผมไม่คิดจะย้ายไปใช้ Zsh
    เครื่องมือที่ดีทำให้การใช้คอมพิวเตอร์เป็นเรื่องสนุก

    • ติดตั้ง Homebrew ก่อน แล้วค่อยใช้มันติดตั้ง Sublime กับ Bash ก็ได้

  • ช่วงหลังผมย้ายกลับจาก Nix มา Homebrew อีกครั้ง และมีเหตุผลใหญ่ ๆ อยู่สามข้อ
    ดูเหมือนว่า Brew จะรองรับแพ็กเกจที่มีอยู่ได้ดีกว่า Nix. Nix ดูเหมือนจะมีบางแพ็กเกจที่ไม่ได้รับการดูแลรักษาเท่าที่ควร
    การรองรับ Mac ก็ดีกว่าด้วย. แพ็กเกจบางตัวใน Nix ปิดฟังก์ชันไว้บน macOS ซึ่งน่าจะเป็นเพราะผู้ดูแลแพ็กเกจนั้นไม่มี Mac สำหรับทดสอบ
    ประสบการณ์ผู้ใช้ก็ดีกว่า
    แน่นอนว่าผมยังคิดถึงความสามารถในการทำสภาพแวดล้อมของ Nix ให้ทำซ้ำได้ และความสามารถในการสร้าง flake ที่รวมแพ็กเกจเฉพาะได้ง่าย ๆ แต่โดยรวมแล้ว Brew ดึงผมกลับมา. ถึงอย่างนั้นผมก็ยังชอบ Nix อยู่ และที่บริษัทก็ใช้ Nix

    • ผมใช้ nix-darwin และจัดการแพ็กเกจ Homebrew จากตรงนั้นด้วย. น่าลองดู
      อยากรู้เหมือนกันว่าที่บริษัทคุณใช้ Nix กับอะไรบ้าง. มีอยู่ไม่กี่จุดที่ดูเหมือน Nix จะเหมาะ แต่ก็ยังชี้ชัดได้ยาก
    • ผมสนใจ Nix เพราะคิดว่าน่าจะใช้ตั้งค่าและจัดการการกำหนดค่าฟีเจอร์ของ macOS แบบอัตโนมัติได้
      แต่ส่วนใหญ่ก็แค่รัน defaults หรือเครื่องมือคั่นกลางบางตัวเท่านั้น
      สุดท้ายผมก็ยังใช้ Brew ต่อ และเขียนฟังก์ชัน setupmac() แบบ idempotent ไว้ใน bash_profile. ผมใช้ Bash 5 และให้ ChatGPT ช่วยเรื่องคำสั่ง defaults เจ๋ง ๆ ได้ดีมาก
      พอมี Brewfile ที่เก็บไว้ใน dotfiles ด้วย มันก็แก้ปัญหาการตั้งค่าบัญชีใหม่หรือปัญหาการตั้งค่า Mac ได้แทบทั้งหมดแล้ว ดังนั้นจึงไม่ต้องใช้เครื่องมือใหญ่โตแบบนั้น

  • Homebrew เป็นโครงการไม่แสวงหากำไรที่ดำเนินงานโดยอาสาสมัครทั้งหมด ไม่ใช่พนักงาน
    การจ่ายค่าระบบ continuous integration, ซอฟต์แวร์ที่จำเป็นต่อการปรับปรุงในอนาคต, ฮาร์ดแวร์ และค่าโฮสต์ ต้องใช้เงินทุน
    เขาบอกว่าเงินบริจาคทั้งหมดจะถูกนำไปใช้เพื่อทำให้ Homebrew ดีขึ้นสำหรับผู้ใช้ จึงน่าพิจารณาการสนับสนุนแบบประจำผ่าน GitHub Sponsors, OpenCollective หรือ Patreon
    ผมบริจาคให้โครงการโอเพนซอร์สที่ตัวเองได้ประโยชน์มามาก แต่ไม่เคยคิดเรื่อง Homebrew อย่างจริงจังมาก่อน ตอนนี้คงต้องสนับสนุนบ้างแล้ว

    • น่าแปลกที่ Apple หรืออย่างน้อยบริษัทพัฒนาซอฟต์แวร์รายใหญ่ที่เน้น Mac ไม่ได้สนับสนุน Homebrew

  • สงสัยว่า Homebrew จะใส่กลไกคูลดาวน์อะไรสักอย่างได้ไหม
    สิ่งเดียวที่ผมอยากไว้วางใจให้ปล่อยโค้ดใหม่ลงเครื่องผมอย่างรวดเร็วคือ Apple กับเบราว์เซอร์ เพราะเบราว์เซอร์ต้องรับมือกับอินพุตที่ไม่น่าเชื่อถือมากกว่าสิ่งอื่นใด
    นอกเหนือจากนั้น ไม่ว่าจะเป็น vscode และส่วนขยาย, npm, homebrew หรือแอปที่อัปเดตอัตโนมัติ ผมอยากรอสักสองสามวันมากกว่า
    แม้อาจมี 0-day บางกรณีที่ต้องข้ามคูลดาวน์ แต่ตอนนี้ผู้ใช้ก็ยังเสี่ยงต่อ 0-day อยู่ดีจนกว่าจะรัน brew upgrade

    • https://docs.brew.sh/Supply-Chain-Security อธิบายไว้ว่าเขาจัดการเรื่องคูลดาวน์อย่างไร และทำไมโปรไฟล์ความเสี่ยงจึงต่างจาก NPM มาก
      นอกจากนี้ สำหรับสิ่งที่ดึงมาจาก NPM/PyPI/RubyGems แล้วนำมาจัดแพ็กเกจ ซึ่งอาจเป็นเป้าหมายของการโจมตีแบบนี้ ก็มีการใช้คูลดาวน์อยู่แล้วทั้งตอนจัดแพ็กเกจและตอนสร้าง PR สำหรับอัปเดตเวอร์ชันใหม่
    • ที่พูดถึงตรงนี้คือฟีเจอร์อย่าง --minimum-release-age หรือ minimumReleaseAge เพื่อช่วยลดความเสี่ยงจากการโจมตีซัพพลายเชน
      การโจมตีแบบนี้มักถูกตรวจพบภายในไม่กี่วันหลังการเจาะระบบ
      ตัวอย่างของ Bun อยู่ที่ https://bun.com/docs/pm/cli/install#minimum-release-age
    • ส่วนใหญ่จัดการด้วยrelease channel เช่น brew set-channel stable/edge
      สัปดาห์นี้หลัง Elixir 1.20 ออก ผมมีเวลาแค่ไม่กี่นาทีจะลองใช้ แต่ Brew ยังตามไม่ทันเลยทำให้หงุดหงิด
      erl และ elixir ติดตั้งด้วยวิธีอื่นได้ และส่วนตัวผมก็ชอบ toolchain ของมันเองมากกว่า แต่ตอนนั้นมันไม่คุ้มจะไปทำแบบนั้น
      Brew มีหรือเคยมีตัวเลือก source สำหรับบาง recipe และถ้ามองแบบหยวน ๆ นั่นก็ถือเป็นทางออกพื้นฐานอย่างหนึ่ง
    • ทั้งหมดนี้เป็นrolling release แต่ใน Homebrew คนที่ต้องอัปเวอร์ชันคือผู้ดูแล Homebrew ไม่ใช่ผู้เขียนซอฟต์แวร์
      ยกเว้นกรณีที่ผู้เขียนส่ง PR เข้า Homebrew core หรือออก Tap ของตัวเอง. อยากรู้ว่า Arch จัดการเรื่องนี้อย่างไร
    • มีอยู่ในรีลีสนี้แล้ว. ดูหัวข้อ “Cooldowns, livecheck and bumping”

  • ขอปรบมือให้ทุกคนที่ทำให้ Homebrew เป็นไปได้ ลองพิจารณาสนับสนุนโครงการได้ที่: https://opencollective.com/homebrew

  • การยุติการรองรับ Intelให้ความรู้สึกค่อนข้างหักดิบ
    คนที่ชอบใช้ Mac เป็นเซิร์ฟเวอร์แทบทั้งหมดใช้เครื่องเก่า และส่วนมากก็เป็น Intel. พวกเขาจะเสียการรองรับก่อน Apple ถึง 1 ปี
    ผมเข้าใจว่าการรองรับ Intel เป็นงานหนักและเป็นเรื่องของการเลือก แต่ก็เห็นว่าควรหาวิธีให้ Homebrew รองรับ Intel ให้นานที่สุดเท่าที่จะทำได้

    • ตรงกันข้าม ผมคิดว่าคนรัก Apple ส่วนใหญ่แบบท่วมท้นได้ย้ายไปใช้Apple Siliconกันหมดแล้ว
      คนที่ใช้ Mac เก่าเป็นเซิร์ฟเวอร์น่าจะมีสัดส่วนไม่ถึงระดับที่เกินกว่าค่าความคลาดเคลื่อนจากการปัดเศษ
    • ถ้า Apple เอาทรัพยากรสักส่วนมาใช้ดูแลสิ่งอย่าง Homebrew หรือจ่ายให้คนที่ทำงานนี้ สถานการณ์อาจต่างออกไป
    • ณ จุดนี้ Mac Intel ที่ว่าก็น่าจะประมาณ Mac mini ปี 2018 ซึ่งรันได้ถึงแค่ Sequoia และก็จะหมดการรองรับพร้อมกับตอนที่ Homebrew เลิกรองรับ Intel
      ถ้าต้องการการรองรับ Intel, MacPorts ยังรันได้ถึง Leopard อยู่เลย
    • รองรับแฟลก --no-quarantine ก็ถูกถอดออกเหมือนกัน
      ช่วงนี้ผมใช้ Homebrew แค่กับ cask บางตัว และพยายามหลีกเลี่ยงให้มากที่สุด. เครื่องมือ CLI ใช้ Nix, Home-Manager และ Nix-Darwin
    • โชคดีที่เครื่องพวกนั้นยังเหมาะอย่างยิ่งสำหรับดิสโทร Linux

  • ผมเจอ การอัปเกรดแบบบังคับ ที่เลี่ยงไม่ได้บ่อยเกินไป เลยเลิกใช้ Homebrew เป็นการส่วนตัว
    ตอนนี้ใช้ Mise คู่กับ MacPorts เพื่อหลีกเลี่ยงการพังแบบไม่แจ้งล่วงหน้าและการบังคับให้ตกรุ่น
    แถม Mise ยังอัปขึ้นเป็นเวอร์ชันใหม่ตามต้องการได้ แต่ Homebrew ต้องรอให้ Tap อัปเกรดเมื่อไหร่ก็เมื่อนั้น llama.cpp Tap บางทีก็ข้ามไปทีละ 10 รีลีส

    • ดีใจจริง ๆ ที่คุณเจอเวิร์กโฟลว์ที่เหมาะกับตัวเองแล้ว
      สำหรับคนที่ยังใช้ Homebrew อยู่ เราทุ่มงานไปมากเพื่อให้มันอัปเกรดเฉพาะตอนที่จำเป็นจริง ๆ และแสดงให้ผู้ใช้เห็นก่อนอัปเกรด ซึ่งรวมอยู่ในรีลีสนี้ด้วย
    • ผมก็กำลังจะถามเหมือนกันว่ามีใครเคยเจอประสบการณ์คล้าย ๆ กันไหม
      ผมใช้ MacPorts มาหลายปีแล้วเพื่อติดตั้งเครื่องมือพัฒนา มันสม่ำเสมอกว่ามาก และไม่มี Python เวอร์ชันเมเจอร์ใหม่โผล่มาแบบสุ่มให้ตกใจ
      ผมใช้ Homebrew แค่ติดตั้งแอปอย่าง Firefox, Slack, Spotify ที่ MacPorts ไม่มี
      แน่นอนว่าหลายปีมานี้ผมก็พยายามย้าย Python ไปใช้ uv และ nodejs ไปใช้ pnpm อยู่แล้ว ดังนั้นตอนนี้มันอาจไม่ใช่ปัญหาใหญ่สำหรับผมอีกต่อไป
    • ผมย้ายไป MacPorts เพราะตาราง ยกเลิกช่วงซัพพอร์ต ของ Homebrew ค่อนข้างดุดัน: https://docs.brew.sh/Support-Tiers
      iMac ที่ผมใช้ทุกวันตอนนี้ตกไปอยู่ในถัง Tier-3 แบบ “ไสหัวไป” แล้ว
      ผมชอบ Homebrew มากจริง ๆ ในช่วงสั้น ๆ ที่ยังใช้งานได้ แต่ไม่คิดจะขึ้นลู่วิ่งอัปเดตฮาร์ดแวร์เพื่อให้ใช้มันต่อไปได้
    • ตอนนี้ผมย้ายของส่วนใหญ่ไป Mise แล้ว แต่ของที่ยังเหลือคงต้องลองดู MacPorts
    • Nix ก็น่าลองดูเหมือนกัน ถึงแพ็กเกจบน Darwin จะยังไม่นิ่งอยู่บ้าง แต่การมี development shell ข้ามแพลตฟอร์มเวลาต้องสลับไปมาระหว่าง Mac กับ Linux บ่อย ๆ นั้นดีมาก