Flox 1.0 – ทำให้สภาพแวดล้อมการพัฒนาเป็นโค้ดด้วยโอเพนซอร์สที่ใช้ Nix

 (github.com/flox)
3 คะแนน โดย GN⁺ 2024-03-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Flox คือ แพลตฟอร์มสภาพแวดล้อมซอฟต์แวร์ สำหรับทีมวิศวกรรม ที่จัดการสภาพแวดล้อมซึ่งทำซ้ำได้เหมือนกันตั้งแต่โน้ตบุ๊กของนักพัฒนาไปจนถึง CI และโปรดักชันด้วย manifest เดียว
  • แม้จะสร้างอยู่บน Nix แต่ความรู้เรื่อง Nix เป็นเพียงทางเลือก โดยใช้ manifest แบบประกาศและอินพุต content hash ที่ตรึงไว้ด้วยวิทยาการเข้ารหัสเพื่อลดปัญหา environment drift
  • ทำงานได้บน macOS, Linux และ Windows WSL2 สามารถค้นหาและติดตั้ง แพ็กเกจกว่า 120,000 รายการ จาก Nixpkgs รวมถึง build และ publish ซอฟต์แวร์ของตนเองเป็นแพ็กเกจที่ทำซ้ำได้
  • ใช้ลำดับงาน flox init, flox install, flox activate เพื่อสร้างสภาพแวดล้อมแบบแยกต่อโปรเจ็กต์ เมื่อ activate แล้วเครื่องมือจะปรากฏขึ้น และเมื่อออกจากสภาพแวดล้อมก็จะหายไป ช่วยให้ระบบสะอาดอยู่เสมอ
  • มุ่งเน้นการจัดการวงจรชีวิตสภาพแวดล้อมในระดับองค์กร ครอบคลุมการแชร์ผ่าน FloxHub, การสร้าง OCI image, การรัน service, SBOM·การแพตช์ CVE·SCA และสภาพแวดล้อมการรันแบบกำหนดแน่นอนสำหรับ AI coding agent

ปัญหาที่ Flox ต้องการแก้

  • Flox เป็นแพลตฟอร์มที่กำหนด สภาพแวดล้อมการพัฒนา ด้วยไฟล์เดียว และทำให้สามารถรันสภาพแวดล้อมเดียวกันได้บนโน้ตบุ๊กของนักพัฒนา, CI และโปรดักชัน
  • หาก package manager แบบดั้งเดิมมุ่งเน้นการติดตั้งแพ็กเกจบนเครื่องเดี่ยว Flox จะจัดการ วงจรชีวิตของแพ็กเกจและสภาพแวดล้อม ทั้งระดับองค์กร
  • คุณสมบัติหลักมี 3 ข้อ
    • Declarative: อธิบายเครื่องมือ ตัวแปรสภาพแวดล้อม และ service ที่โปรเจ็กต์ต้องใช้ไว้ในไฟล์เดียว
    • Reproducible: นิยามเดียวกันสามารถสร้างสภาพแวดล้อมเดียวกันได้บนทุกระบบที่รองรับ
    • Composable: สามารถจัดชั้นสภาพแวดล้อมตามโปรเจ็กต์ ทีม หรือ pipeline ได้

ผู้ใช้เป้าหมายและสภาพแวดล้อมการใช้งาน

  • ทีม Platform·DevX สามารถทำให้ toolchain ทั่วทั้งองค์กรเป็นมาตรฐาน และขยายสภาพแวดล้อมอ้างอิงได้โดยไม่ต้องบังคับให้เรียนรู้ Nix
  • ทีม Security·AppSec สามารถจัดการ SBOM, การตอบสนองต่อ CVE อย่างรวดเร็ว, แหล่งที่มาของ dependency และ reproducible build ได้
  • นักพัฒนา สามารถใช้สภาพแวดล้อมต่อโปรเจ็กต์ที่ทำซ้ำได้บน macOS, Linux และ Windows WSL2 โดยทำงานในลักษณะใกล้เคียง virtual environment มากกว่าคอนเทนเนอร์หรือ VM
  • AI coding agent จะได้สภาพแวดล้อมแบบกำหนดแน่นอนที่สามารถ build และรันโค้ดที่สร้างขึ้นได้ในแบบเดียวกันทุกครั้ง
    • ตัวอย่างเป้าหมายได้แก่ Claude Code, Cursor, Copilot และ Codex

ความสามารถในการทำซ้ำและความปลอดภัยของซัพพลายเชน

  • สภาพแวดล้อม Flox ถูกกำหนดด้วย manifest แบบประกาศ และล็อกไว้กับ อินพุต content hash ที่ตรึงไว้ด้วยวิทยาการเข้ารหัส
  • lockfile เดียวกันจะถูกตีความเป็นแพ็กเกจเดียวกันในทุกระบบที่รองรับ จึงทำให้สภาพแวดล้อมระหว่างเครื่องคงความเหมือนกัน
  • สามารถใช้คำนิยามสภาพแวดล้อมเดียวกันบนโน้ตบุ๊กของนักพัฒนา, AI agent sandbox, CI และโปรดักชันได้
  • สามารถใช้ แพ็กเกจกว่า 120,000 รายการ จาก Nixpkgs
  • สามารถ build ซอฟต์แวร์ของตนเองจากซอร์สให้เป็นแพ็กเกจที่ทำซ้ำได้ และ publish ให้ทั้งทีมใช้งานร่วมกัน
  • ด้วยพื้นฐานของ reproducibility จึงช่วยให้การสร้าง SBOM, software composition analysis (SCA), การแพตช์ช่องโหว่และ CVE อัตโนมัติ, การตรวจสอบแหล่งที่มาของ dependency และ build ที่ตรวจสอบย้อนหลังได้ ทำได้ง่ายขึ้น

การติดตั้งและเวิร์กโฟลว์พื้นฐาน

  • Flox CLI ติดตั้งแบบเนทีฟได้บน macOS, Linux และ Windows WSL2
    • macOS: brew install flox หรือไฟล์ติดตั้ง .pkg
    • Linux: .deb สำหรับ Debian/Ubuntu, .rpm สำหรับ Fedora/RHEL
    • Windows: ใช้แพ็กเกจ Linux บน WSL2
  • ลำดับการใช้งานพื้นฐานคือสร้างสภาพแวดล้อมภายในโปรเจ็กต์ ติดตั้งแพ็กเกจที่ต้องใช้ แล้วจึง activate สภาพแวดล้อม
    • flox init: สร้างสภาพแวดล้อมในโปรเจ็กต์
    • flox install python3 nodejs: ติดตั้งแพ็กเกจลงในสภาพแวดล้อม
    • flox activate: เข้าใช้งานสภาพแวดล้อม
  • ตัวอย่างใน README แสดงว่าในสภาพแวดล้อมที่ activate แล้ว python3 --version ทำงานเป็น Python 3.13.13 และ node --version เป็น v24.15.0
  • เมื่อออกจากสภาพแวดล้อม เครื่องมือที่ติดตั้งจะหายไป ช่วยป้องกันการชนกันระหว่างโปรเจ็กต์และทำให้ระบบสะอาด

ฟีเจอร์หลัก

  • Create: ใช้ flox init เพื่อสร้างสภาพแวดล้อมแบบประกาศไว้ข้างโค้ด และสามารถ activate อัตโนมัติได้
  • Search: ใช้ flox search เพื่อค้นหาแพ็กเกจกว่า 120,000 รายการใน Nixpkgs
  • Share: ใช้ flox push / flox pull เพื่อให้สมาชิกทีมดึงสภาพแวดล้อมมาตรฐานเดียวกันจาก FloxHub
  • Containerize: ใช้ flox containerize เพื่อสร้าง OCI image จากสภาพแวดล้อม Flox โดยไม่ต้องมี Dockerfile
  • Build & publish: ใช้ flox build / flox publish เพื่อ build ซอฟต์แวร์ของตนเองเป็นแพ็กเกจที่ทำซ้ำได้ และ publish ให้ทีมใช้งาน
  • Services: ใช้ flox services start เพื่อรันฐานข้อมูล คิว และโปรเซสเบื้องหลังเป็นส่วนหนึ่งของสภาพแวดล้อม โดยจะเริ่มเมื่อ activate และหยุดเมื่อออกจากสภาพแวดล้อม
  • Configure: กำหนดตัวแปรสภาพแวดล้อม shell hook และ activation script แบบ declarative ใน manifest.toml
  • AI-ready: ผ่าน flox-agentic เพื่อรองรับให้ AI coding agent build และรันด้วย dependency เดียวกันในทุกครั้งที่รัน

ตำแหน่งของ Flox สำหรับผู้ใช้ Docker และ Nix

  • Flox ไม่ใช่เทคโนโลยีคอนเทนเนอร์ และไม่ใช่ตัวแทนของ Docker
  • ใน Docker มักมีกรณีที่การแพ็กเกจซอฟต์แวร์และการแยกคอนเทนเนอร์ถูกปะปนกัน แต่ Flox มีจุดยืนว่าควรแยก การแพ็กเกจซอฟต์แวร์ ออกจากวิธีการแยกที่เลือกใช้
  • สภาพแวดล้อม Flox ทำงานได้ในแบบเดียวกันบน bare metal, VM และคอนเทนเนอร์
  • flox containerize จะสร้าง OCI image ที่มีสภาพแวดล้อมซอฟต์แวร์รวมอยู่ และสามารถใช้ร่วมกับ Docker, Kubernetes และคอนเทนเนอร์รันไทม์อื่น ๆ ได้
  • สำหรับผู้ใช้ Nix, Flox ไม่ใช่ตัวแทนทดแทน แต่เป็นเครื่องมือเสริม
    • มี FloxHub เป็นบริการศูนย์กลางสำหรับสภาพแวดล้อมการทำงานร่วมกันและการแชร์แพ็กเกจ
    • รวม activation hook, service และ shell profile ไว้ในไฟล์ TOML แบบประกาศเพียงไฟล์เดียว

ที่มาและแหล่งข้อมูลสนับสนุน

  • Flox เริ่มต้นจากการ deploy Nix ระดับองค์กรขนาดใหญ่ของ D.E. Shaw group และถูกใช้เพื่อทำให้ Nix เข้าถึงได้ง่ายขึ้นในองค์กรวิศวกรรมขนาดใหญ่
  • แหล่งข้อมูลที่เกี่ยวข้อง
    • Documentation: บทช่วยสอน เอกสารอ้างอิง และคู่มือ
    • FloxHub: สำรวจและแชร์สภาพแวดล้อม
    • Discourse: คำถาม การสนทนา และประกาศ
    • Blog: บทความเชิงลึกและเวิร์กโฟลว์
    • VS Code extension: จัดการสภาพแวดล้อม Flox จากในเอดิเตอร์
  • สอบถามเรื่องความปลอดภัยได้ที่ security@flox.dev
  • ไลเซนส์ของ Flox CLI คือ GPLv2

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

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

 
GN⁺ 2024-03-14
ความคิดเห็นบน Hacker News

  • Ron ยินดีด้วยกับการเปิดตัว สิ่งที่สงสัยคือ โมเดลรายได้ จะเป็นอย่างไร
    มีทั้ง CEO บริษัท และพนักงาน และดูจาก Crunchbase เหมือนว่าจะได้รับ เงินลงทุน 24 ล้านดอลลาร์ แต่กลับหาข้อมูลราคาไม่เจอทั้งในหน้าแลนดิ้งเพจหรือเอกสาร
    แม้จะล็อกอิน FloxHub ด้วยโปรไฟล์ GitHub ก็ยังไม่เห็นตัวเลือกการชำระเงิน เลยอยากรู้ว่าแผนคืออะไร

    • ขอบคุณที่ทักเรื่องนี้ เหตุผลสำคัญที่เราเริ่ม Flox ก็คือรูปแบบฟรีและโอเพนซอร์สที่เปิดตัววันนี้ และจากนี้จะใส่อะไรเพิ่มอีกมาก
      ไคลเอนต์โอเพนซอร์สที่เปิดตัววันนี้และบริการ FloxHub สำหรับแชร์ environment จะให้ ฟรีถาวร
      ต่อไปเราอยากนำเสนอ private software catalog ที่ทรงพลังยิ่งขึ้นซึ่งวางอยู่บน Flox Catalog พื้นฐาน
      หากคุณต้องการแจกจ่ายผลลัพธ์ที่สร้างขึ้นเอง หรือจำเป็นต้องใช้เวอร์ชันแพ็กเกจโอเพนซอร์สที่ถูกแก้ไขภายใน Flox เราวางแผนจะทำให้สร้างแคตตาล็อกของตนเองได้ง่าย เพื่อเสริม Flox Catalog ที่ใช้ฟรีตลอดไป
      ในระยะยาว เราตั้งใจจะขายโซลูชันสำหรับองค์กรในรูปแบบ subscription และบริการ เพื่อช่วยให้องค์กรจัดการซัพพลายเชนซอฟต์แวร์ที่กว้างและกระจัดกระจายได้ดีขึ้น และมองว่าการให้องค์กรร่วมออกค่าใช้จ่ายในการพัฒนาเครื่องมือเฉพาะทางนั้นสมเหตุสมผล
    • ได้เงินมา 24 ล้านดอลลาร์ก็น่าตกใจอยู่ ที่นี่ผมยังมองไม่ค่อยออกว่าจะไปถึง ทางออกมูลค่า 2.4 พันล้านดอลลาร์ ได้อย่างไร แต่ก็ขอให้โชคดี

  • ทุกครั้งที่เห็นข้อความทำนองว่า “ทำให้ Nix ง่ายขึ้นสำหรับผู้ใช้ใหม่” ใน README หรือคำพูดคล้ายกันก็สะดุดใจเสมอ
    ผมคิดว่าตัวเองก็พอมีความสามารถ แต่ไม่เคยมีสักครั้งที่ใช้ Nix แล้วรู้สึกว่า “นี่มันง่าย”
    ผมชอบแนวคิดของ Nix มาก แต่ ประสบการณ์ผู้ใช้ แย่มาก เครื่องมือนี้อาจแก้ปัญหานั้นได้ก็จริง แต่กว่าจะไปถึงจุดนั้นต้องคลำทางผ่านเอกสารที่แทบไม่มี และวิธีการที่ถูกทิ้งไปแล้ว พร้อมปรับแต่ง config ไม่รู้จบ จนชวนให้หงุดหงิด
    ยังไงก็ตาม ทุกครั้งที่เห็นอะไรเกี่ยวกับ Nix ก็ทำให้นึกว่า “รอวันที่สิ่งนี้จะง่ายขึ้นอยู่”

    • ถ้าหมายถึงประโยคที่ว่า “Flox เริ่มต้นระหว่างที่นำ Nix ไปใช้ในกลุ่ม D. E. Shaw และพิสูจน์คุณค่าได้อย่างรวดเร็วด้วยการทำให้ Nix ง่ายขึ้นสำหรับผู้ใช้ใหม่” มันฟังเหมือนตรงกันข้ามกับการตีความเดิมนะ
    • ประโยคนั้นไม่ได้หมายความว่า Nix ง่ายสำหรับผู้ใช้ใหม่ แต่หมายความว่า Flox ทำให้ Nix ง่ายขึ้น
    • ประสบการณ์เหมือนกันเป๊ะ ผมลองใช้ NixOS มาค่อนข้างนานแต่ก็ยังไม่คุ้นกับ .nix หรือ flakes
      แนวคิดพื้นฐานหลุดออกจากหัวตลอด เวลาเซ็ตอะไรใหม่ก็ต้องกลับไปค้นใหม่ สุดท้ายก็เหนื่อย
      การดีบักปัญหาก็ยาก ต้องไปคุ้ยคำสั่งเฉพาะทางมาก ๆ กับระบบไฟล์จากนรกเพื่อหาว่าอะไรผิด
      แนวคิดดี แต่พอใช้งานจริงกลับรู้สึกว่ามันขวางทางมากเกินไป
    • ผมชอบ Nix และก็เคยช่วยแพ็กเกจใน nix repository อยู่พอสมควร แต่จะบอกว่าง่ายก็คงไม่ได้
      ผมมีพื้นฐาน Haskell เลยอาจรู้สึกคุ้นมือมากกว่า แต่ ตัวไวยากรณ์เองก็ไม่ได้เข้าใจง่ายสำหรับผู้ใช้ใหม่
    • เห็นด้วยอย่างแรง มองเห็นข้อดีนะ แต่ เส้นโค้งการเรียนรู้ช่วงแรก ชันมาก
      คล้ายตอนเรียน Rust เลย เลยก็สนุกดีเหมือนกัน

  • ปัญหาแกนหลักของผลิตภัณฑ์แนว “ให้พลังของ Nix โดยไม่ต้องมีเส้นโค้งการเรียนรู้” คือด้านหลังมันก็ยังเป็น Nix กับ /nix/store อยู่ดี และ Nix ก็จงใจไม่ทำความสะอาดเรื่องนี้ให้อัตโนมัติ
    พอผู้ใช้ลองใช้เครื่องมือที่ซ่อน Nix ไว้ สุดท้ายดิสก์ก็เต็ม แต่ไม่รู้จะลดการใช้พื้นที่อย่างไร แบบนี้คงเรียกว่าเป็นมิตรกับผู้ใช้ได้ยาก
    ถ้าผู้ใช้รู้ตัวว่ากำลังติดตั้ง Nix และผ่านกระบวนการเรียนรู้ ก็จะสร้าง mental model ได้ว่า /nix/store คืออะไรและต้องดูแลอย่างไร ซึ่งต่างกัน
    เลยสงสัยว่ามีแผนจะจัดการกับ ความซับซ้อนระดับล่าง นี้อย่างไร

    • ถ้ารองรับ rollback และ history ดิสก์ก็มีสิทธิ์เต็มอยู่แล้ว ใน Nix มักมี GC roots หลายตัวที่ชี้ไปยังโปรไฟล์และแพ็กเกจ ทำให้เก็บกวาดไม่ได้
      environment ของ Flox ไม่ได้เป็นแค่ symbolic link แต่เป็นรูปแบบเชิงประกาศ และภายในมี flakes ด้วย จึงลบออกได้และถ้าจำเป็นก็สร้างกลับมาใหม่ได้
      เพราะแบบนั้น การเก็บขยะจึงทำลายน้อยกว่าตอนใช้ nix-env/nix profile และสามารถลบ generation เก่าได้แบบเชิงรุกมากกว่า
      กลยุทธ์คือรับประกันให้ได้เสมอว่ามีวิธีแบบเชิงประกาศและทำซ้ำได้สำหรับกู้คืนสิ่งที่ลบไป แล้วค่อยใช้ heuristic อย่างพื้นที่ว่าง อายุ การไม่ได้ใช้งานล่าสุด หรือความถี่การใช้งานต่ำ เพื่อหลีกเลี่ยงไม่ให้ดิสก์เต็ม
    • เทียบกับ Docker หรือ Bazel แล้วเป็นอย่างไร
      ในทางกลับกัน ผมไม่เคยเจอปัญหานี้กับ Nix มันบอกวิธีล้างขยะชัดเจน และก็ตรวจสอบได้ง่ายว่าอะไรยังค้างอยู่และเพราะอะไร
      ที่ไม่ได้เปิดใช้เป็นค่าเริ่มต้นก็เพราะเหมือน garbage collector แบบอื่น ๆ มันอาจรบกวนได้ และไม่มีนโยบายแบบเดียวที่เหมาะกับทุกคน
      สุดท้ายถ้ามี GC roots มากเกินไป ก็ต้องตัดสินใจบางอย่างอยู่ดี
    • Nix รองรับ garbage collection อยู่แล้ว
      ทุกครั้งที่เราใช้คอมพิวเตอร์ เบื้องหลังก็มีเรื่องซับซ้อนแบบไม่น่าเชื่อเกิดขึ้นเป็นพันอย่างอยู่แล้ว ผมไม่ค่อยเข้าใจว่าทำไมการทำ abstraction ให้กับ Nix ถึงถูกมองว่าเป็นกรณีพิเศษ
    • ที่ทำงานก็มีปัญหาเดียวกันกับ Bazel ผ่านไปไม่กี่เดือนพื้นที่ดิสก์บนเครื่องนักพัฒนาก็ไม่พอ
    • แค่ตั้งให้ Nix garbage collect ทุก 30 นาทีก็พอ

  • ขอแสดงความยินดีกับการเปิดตัว ฉันชอบ Nix มากจริง ๆ แต่ก็ยอมรับว่า ประสบการณ์การเริ่มต้นใช้งาน นั้น ต่อให้มองในแง่ดีก็ยังแย่ และในแง่ร้ายที่สุดก็ถึงขั้นน่าหงุดหงิดมาก
    เพราะอย่างนั้น ความพยายามที่จะทำให้มันเข้าถึงง่ายขึ้นจึงเป็นสิ่งที่น่ายินดี
    CLI แบบ imperative ก็ใกล้เคียงกับวิธีที่หลายคนคาดหวังและรู้สึกคุ้นเคยมากกว่า จึงคิดว่าเป็นทิศทางที่ดี
    และก็เห็นด้วยมากกับการทำให้กระบวนการใช้สภาพแวดล้อมของคนอื่นง่ายขึ้น
    แต่สิ่งสำคัญที่ดูเหมือนขาดหายไปคือ การผสานรวมกับ IDE การสตาร์ต IDE จากบรรทัดคำสั่งภายในสภาพแวดล้อมนั้นไม่ใช่เรื่องที่เข้าใจได้ตรงไปตรงมาสำหรับเพื่อนร่วมงานหลายคน และฉันเองก็เคยวินิจฉัยว่านี่เป็นต้นตอของปัญหาจริงมาแล้วหลายครั้ง
    ฉันสงสัยว่าถ้าจำเป็นต้องลงไปใช้ “Nix ของจริง” จะเป็นอย่างไร ตัวอย่างเช่น ในสภาพแวดล้อมที่ซับซ้อนขึ้นอีกหน่อยอย่างการตั้งค่า toolchain สำหรับ Rust cross-compilation ก็กลัวว่าจะเจอทางตัน
    จากตัวอย่างการพัฒนา Rust ฉันเคยต้องใส่ shellHook ยาว ๆ ไว้ใน flake เพื่อให้ Rust-Analyzer ทำงานได้ถูกต้อง ก็เลยสงสัยว่าใน Flox จะทำการตั้งค่าแบบนี้ได้อย่างไร
    ไม่แน่ใจว่าตั้งใจจะ abstract เรื่องพวกนี้ออกไปเลยหรือไม่ และถ้าไม่ใช่ ผู้ใช้ที่ไม่รู้จัก Nix จะหาคำตอบได้อย่างไร
    ไม่ได้จะบอกว่าเป็นไปไม่ได้เด็ดขาดนะ แค่อยากให้มันไปได้สวยจริง ๆ แต่ตอนนี้ยังมองไม่ค่อยออกว่าจะทำอย่างไร

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

  • ฉันสงสัยว่าข้อดีของการใช้ Flox แทน nix-shell หรือ nix develop แบบปกติคืออะไร

    • ฉันเป็นพนักงานของ Flox ถ้าจะเริ่มจากความสัมพันธ์กับเครื่องมือของ Nix เป้าหมายก็คือทำให้มัน เป็นมิตรกับผู้ใช้มากขึ้น
      เราอยากให้คนใช้งานได้สำเร็จโดยไม่ต้องเรียนรู้ภาษา expression ของ Nix หรือเข้าใจโครงสร้างภายในของ Nix
      นอกจากนี้ยังเพิ่มแนวทางและการขัดเกลาเข้าไปพอสมควร ตัวอย่างเช่น เรามีอินเทอร์เฟซแบบผสม imperative/declarative ดังนั้นถ้ารัน flox install && flox list การเปลี่ยนแปลงจะถูกสะท้อนลงใน TOML ในขณะที่ nix develop คุณต้องไปแก้ไข Nix expression เอง
      nix develop จะพาเข้า bash shell แต่ flox activate สามารถเข้าได้ทั้ง bash หรือ zsh และเราก็มีแผนจะเพิ่มการรองรับ fish
      เรารองรับการจัดการสภาพแวดล้อมด้วย Git แบบเดียวกับเครื่องมือของ Nix และยังเพิ่มการแชร์สภาพแวดล้อมในแบบที่เครื่องมือเหล่านั้นทำไม่ได้ เช่น flox push/flox pull/flox activate -r
      ถ้าคุณสร้างบัญชี คุณจะดูแพ็กเกจในสภาพแวดล้อมของฉันได้ที่ https://hub.flox.dev/mkenigs/default และถ้ามี CLI ก็ตรวจสอบได้ด้วย flox list -r mkenigs/default จากนั้นใช้งานได้ด้วย flox activate -r mkenigs/default
      สำหรับคนที่ไม่รู้ภาษา expression ของ Nix ฉันคิดว่านี่เข้าใจได้ง่ายกว่าการส่งลิงก์ flake.nix ให้มาก
    • ถ้าพูดอีกแบบ ฉันคิดว่าสำหรับวิศวกรแต่ละคน การเรียนรู้เทคโนโลยีพื้นฐานและเครื่องมือที่มากับมันน่าจะดีกว่า
      มีความเป็นไปได้มากพอที่เครื่องมืออย่าง Flox หรือ devenv จะหมดอายุการใช้งาน หรือไล่ตาม nixpkgs ไม่ทัน หรือเจอรูปแบบใดรูปแบบหนึ่งของ software rot
      ขณะที่ nix develop จะยังอยู่ตราบเท่าที่ Nix Flakes ยังอยู่ และก็มีแรงจูงใจที่จะจัดหาเส้นทาง migration ไปสู่วิธีถัดไป
      ที่สำคัญกว่านั้นคือ abstraction ทุกอย่างย่อมมีจุดรั่ว ถึงแม้ Flox CLI จะดูสะอาดกว่า แต่สุดท้ายถ้าอยากใช้อย่างมีประสิทธิภาพก็คงต้องเรียนรู้ Nix อยู่ดี
      ก็เลยไม่แน่ใจว่าจะมีเหตุผลอะไรให้ต้องเรียนรู้มากกว่าสิ่งที่จำเป็นเป็นสองเท่า
    • หรือจะใช้ https://devenv.sh ก็ได้

  • ฉันสงสัยว่ามันเทียบกับโปรเจกต์ Devbox เดิม (https://www.jetpack.io/devbox) อย่างไร
    Flox มี โซลูชันคลาวด์ แบบเลือกใช้ด้วยไหม ติดตั้งแพ็กเกจ Nix เวอร์ชันเฉพาะได้หรือเปล่า และจัดการ dependency แยกตามระบบปฏิบัติการอย่างไร
    ฉันใช้เครื่องมือพวกนี้มา 5 ปีแล้ว ก็เลยอยากรู้ว่า Flox นำอะไรใหม่มาเมื่อเทียบกับของที่มีอยู่แล้ว

  • ฉันไม่เข้าใจจริง ๆ ว่าทำไมต้องใช้สิ่งนี้แทน Nix ปกติ ใครช่วยอธิบายได้ไหม

    • ฉันแค่อยากได้ สภาพแวดล้อมที่สะอาดและทำซ้ำได้ สำหรับแต่ละโปรเจกต์ ฉันพยายามเริ่มต้นกับ Nix มาหลายครั้งแล้ว แต่ทุกครั้งก็รู้สึกท่วมท้นเพราะ Nix ทำอะไรได้เยอะเกินไป
      อันนี้สำหรับฉันดูง่ายกว่าราว 100 เท่า
    • ฉันเข้าใจว่า Nix แก้ปัญหาได้หลายอย่าง และจริง ๆ ก็เดิมพันกับความสามารถนั้นด้วย ถึงได้ลงแรงกับตัว Nix เองไปมาก
      แต่ Nix ถูกสร้างขึ้นจากหลักการพื้นฐานให้มีความเป็นทั่วไปสูงมากตั้งแต่ต้น จึงมี learning curve ที่ค่อนข้างชัน
      Flox เป็นเครื่องมือที่พยายามทำให้ง่ายขึ้นโดยจำกัดขอบเขตของปัญหา และให้นามธรรมกับอินเทอร์เฟซที่เฉพาะทาง เพื่อให้ใช้ความสามารถของ Nix ได้โดยไม่ต้องกลายเป็นผู้เชี่ยวชาญ Nix ตั้งแต่วันแรก
    • การโน้มน้าวเพื่อนร่วมงานให้ใช้ flox หรือ devenv ง่ายกว่าการโน้มน้าวให้ใช้ Nix มาก

  • ฉันสนใจ สภาพแวดล้อมการพัฒนาแบบทำซ้ำได้ มาก และที่ทำงานก็ใช้ development containers ได้ผลดีมาหลายปีแล้ว
    ประมาณ 1 ปีก่อนฉันได้ยินเรื่อง Nix และตอนแรกก็ตื่นเต้นมาก เพราะคำสัญญาของมันยอดเยี่ยมจริง ๆ แต่กระบวนการเริ่มต้นใช้งานสำหรับฉันนั้นโหดร้ายมาก
    ฉันรู้ชัดว่าต้องการสร้างสภาพแวดล้อมการพัฒนาแบบไหน แต่รู้สึกเหมือนพลาดอะไรบางอย่างในแนวทางการเข้าถึงมันอยู่ตลอด
    ดีใจที่มีเครื่องมือใหม่ออกมาพยายามปรับปรุงประสบการณ์โดยรวม และหวังว่าถ้ายังลองต่อไปเรื่อย ๆ สักวันคงจะจับทางได้
    อยากรู้ว่าสำหรับคุณ Nix มัน “คลิก” ขึ้นมาในจุดไหน

    • ขอบคุณสำหรับคำถามนะ นี่เป็นหัวข้อที่ถ้ามา Bay Area แล้วควรคุยกันยาว ๆ พร้อมเบียร์สักแก้ว
      เคยดูวิดีโอ Microservices นี้ไหม https://www.youtube.com/watch?v=y8OnoxKotPQ
      ตอนนั้นฉันเป็นหัวหน้าทีมผลิตภัณฑ์สำหรับนักพัฒนาที่ Facebook และเราเริ่มโปรเจกต์เพื่ออัดความสามารถแบบรีโมตเข้าไปใน local development
      นักพัฒนาหลายพันคนกำลังรอ cold build กันครั้งละ 45 นาที
      หนึ่งในช่วงแรก ๆ คือการวาดภาพ วงจรชีวิตการพัฒนาซอฟต์แวร์ ทั้งหมดออกมา เพื่อหาว่าเราต้องสร้างส่วนไหนของ toolchain ขึ้นใหม่บ้าง
      ถ้าดูไวต์บอร์ดช่วงท้ายวิดีโอ มันเหมือนเป็นช่วงเวลาที่ได้มองเห็นภาพว่าพวกเราทำทุกอย่างให้ซับซ้อนแค่ไหน แล้วก็พาไปสู่ความคิดที่ว่า “นี่ไม่ควรเป็นวิธีที่เราทำงานกัน”

  • ครั้งล่าสุดที่ฉันใช้ Nix ยังมีความสับสนเรื่อง flakes อยู่มาก
    บางบทสอนก็บอกให้ใช้ แต่อีกหลายแห่งก็บอกว่ายังอยู่ระหว่างพัฒนา เลยสงสัยว่าสถานการณ์ดีขึ้นหรือยัง

    • คิดว่าดีขึ้นแล้ว โซลูชันที่เกือบทั้งหมด หรืออาจทั้งหมด ที่ลิสต์ไว้ที่นี่ ดูเหมือนจะใช้ flakes ภายในกันทั้งนั้น: https://news.ycombinator.com/item?id=39696038
      ปัญหาเรื่อง flakes น่าจะมาจากสองอย่าง
      อย่างแรกคือมันติดป้าย experimental มานานเกือบ 5 ปี ทำให้ผู้ใช้ใหม่สับสน แต่ในความเป็นจริงกลับถูกใช้อย่างแพร่หลายแทบทุกที่
      อีกอย่างคือดูเหมือนจะมีความบาดหมางกันระหว่าง https://determinate.systems/ กับผู้ใช้และนักพัฒนา Nix รุ่นเก๋า Determinate Systems ดูเหมือนจะถูกวิจารณ์ว่านำ Nix ไปใช้เพื่อผลประโยชน์ของตัวเองโดยไม่ตอบแทนกลับสู่ชุมชน
      เท่าที่ฉันเข้าใจ Determinate Systems เป็นคนผลักดัน flakes เข้ามา เลยทำให้บางส่วนต่อต้าน
      สรุปคือแทบทุกคนรับ flakes มาใช้แล้ว และไกด์ที่บอกว่าไม่ควรใช้นั้นก็มักจะเก่าแล้ว
      ลิงก์ที่เกี่ยวข้อง: https://discourse.nixos.org/t/introducing-flakehub/32044
    • ช่วงนี้ฉันไม่รู้จักใครที่แนะนำว่าไม่ควรใช้ flakes แล้ว
      ป้าย “experimental” มีความหมายใกล้กับเรื่อง API stability มากกว่าความสมบูรณ์หรือบั๊ก
      ในบางสถานการณ์อาจมีปัญหาด้านประสิทธิภาพอยู่บ้าง แต่ก็มีวิธีเลี่ยง และกำลังทำทางแก้ถาวรอยู่ด้วย
      ถึงอย่างนั้นฉันก็ยังใช้ flakes เยอะทั้งที่บ้านและที่ทำงาน
    • อ้างอิง: แผนสำหรับค่อย ๆ ทำให้ CLI ใหม่และ Flakes มีสถานะเสถียร https://github.com/NixOS/rfcs/pull/136

  • เมื่อคืนฉันลองใช้ Flox บน macOS แล้วเห็นว่ามันติดตั้ง Nix ลงใน default profile แยกจาก Nix ที่ Nix-Darwin จัดการไว้ใน /run/current-system/sw/bin แล้วค่อยทำ symbolic link ของสำเนานั้นไปที่ /usr/local/bin
    อีกทั้งยังไม่มีคำแนะนำสำหรับผู้ใช้ Nix เดิมอยู่แล้ว เช่น ผู้ใช้ NixOS หรือผู้ใช้ดิสโทรอื่นที่ติดตั้ง Nix ไว้แล้วแต่ไม่มีรูปแบบแพ็กเกจของดิสโทรที่ Flox รองรับ
    ฉันเลยสงสัยว่านี่เป็นเพราะ Flox เป็นตัวจัดการโปรไฟล์ third-party ของ Nix ที่ต้องพึ่งพาสิ่งอย่างรูปแบบ Nix profile manifest ที่ยังไม่เสถียร หรือจริง ๆ แล้วมันใช้ร่วมกับ Nix หลายเวอร์ชันได้แต่แค่ยังไม่ได้ทดสอบกันแน่
    และก็อยากรู้ด้วยว่ามองการติดตั้ง Flox แบบอิง Nix ว่าเป็นฟีเจอร์ที่จะรองรับภายหลังหรือเปล่า
    อีกอย่างคือเห็นบอกว่าจะมีการรองรับ fish เลยอยากรู้ว่าจริง ๆ แล้ว shell integration ของคำสั่งย่อย activate อยู่ตรงไหนในซอร์สหรือคอนฟิกของ Flox
    ระหว่างรอการรองรับ fish อย่างเป็นทางการ ฉันพยายามจะผูกใช้งานชั่วคราวด้วยอะไรอย่าง fenv แต่ไล่ดูทั้งตัวติดตั้งและซอร์สแล้วก็ยังไม่ค่อยเห็นจุดที่น่าจะเสียบเข้าไปได้

    • คุณอาจพลาดแท็บ Nix/Generic กับ Nix/NixOS ใน https://flox.dev/docs/install-flox/ ซึ่งฉันก็สงสัยเหมือนกันว่ามันครอบคลุมกรณี ใช้งานควบคู่กัน ที่คุณพูดถึงหรือเปล่า
      ตอนนี้วิธีที่ดีที่สุดในการใช้ fish น่าจะเป็น FLOX_SHELL=zsh flox activate -- fish ฉันคิดว่ายังไม่รองรับ alias แต่ส่วนใหญ่น่าจะใช้งานได้
      ฉันอยากรู้ด้วยว่าคุณตั้งใจจะแฮ็กซอร์สจริง ๆ หรือแค่อยากเข้าใจโครงสร้างเพื่อทำวิธีเลี่ยงชั่วคราว
      ถ้าเป็นเชลล์ที่ไม่ใช่ bash หรือ zsh จะเกิดข้อผิดพลาดแถว ๆ นี้: https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a4827...
      ถ้าคุณอยากลองแก้เอง ฉันยินดีอธิบายบริบทเบื้องหลังเพิ่มเติม