Homebrew เพิ่มคำเตือนเกี่ยวกับ HashiCorp และเตรียมเลิกใช้งาน

 (github.com/Homebrew)
1 คะแนน โดย GN⁺ 2023-10-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Homebrew/homebrew-core PR #139538 เป็นการเปลี่ยนแปลงที่เพิ่มคำเตือนให้ผู้ใช้ใน formula terraform เนื่องจาก การเปลี่ยนไลเซนส์ ของ HashiCorp และแจ้งว่าอาจปิดใช้งานในอนาคต
  • เหตุผลของการเปลี่ยนแปลงคือ หลังจากเปลี่ยนไลเซนส์แล้ว จะ ไม่มีการอัปเดตเวอร์ชันของ terraform ใน homebrew-core อีกต่อไป โดยเน้นให้ผู้ใช้รับทราบเรื่องนี้ตอนติดตั้ง
  • ระหว่างการรีวิวมีการพูดถึง ข้อยกเว้นด้านเวอร์ชัน ว่ารีลีสในอนาคตที่เก่ากว่า 1.6.0 อาจยังรับได้ แต่ก็มีโอกาสเช่นกันว่าจะไม่มีรีลีสลักษณะนั้น
  • หลังจากจัดการ dependency แล้ว PR กลับมาอยู่ในสถานะพร้อมรีวิวอีกครั้งในวันที่ 4 เมษายน 2024 และอัปเดตด้วยคอมมิต terraform: deprecate and add caveat โดยสะท้อนฟีดแบ็กที่ให้ลบข้อความแบบอนาคตกาลออก
  • การเปลี่ยนแปลงสุดท้ายถูกรวมเข้า Homebrew master ผ่าน merge queue เมื่อวันที่ 5 เมษายน 2024 เป็น คอมมิต 4782218 และ PR เลิกใช้งาน terraform ที่เกี่ยวข้อง #168090 ก็ถูกรวมด้วย

การเลิกใช้งาน formula terraform และการเพิ่มคำเตือน

  • จุดประสงค์ของ PR #139538 คือแจ้งผู้ใช้ว่า เนื่องจาก การเปลี่ยนไลเซนส์ ของ HashiCorp ทำให้จะไม่มีการอัปเดตเวอร์ชัน terraform ใน homebrew-core อีกต่อไป
  • คำอธิบายแรกเริ่มมีทิศทางเพื่อแจ้งผู้ใช้ว่า “formula นี้อาจถูกปิดใช้งานในอนาคต”
  • เป้าหมายของการเปลี่ยนแปลงคือ Formula/terraform.rb และภายหลังเส้นทางไฟล์ถูกแสดงเป็น Formula/t/terraform.rb
  • PR นี้ติดป้ายกำกับเช่น formula deprecated, busl-license, go, maintainer feedback

การพูดคุยเรื่องเวอร์ชันและไลเซนส์

  • ระหว่างการรีวิวมีความเห็นว่ารีลีสในอนาคตของ terraform ที่เป็น เวอร์ชันก่อน 1.6.0 อาจยังรับได้
    • อย่างไรก็ตาม ก็มีการระบุด้วยว่าอาจไม่มีรีลีสแบบนั้นเกิดขึ้นจริง
  • คำอธิบายของ PR ใช้ประเด็นที่ว่าหลังการเปลี่ยนไลเซนส์จะไม่มีการอัปเดตเวอร์ชันใน homebrew-core อีก เป็นเหตุผลของการเปลี่ยนแปลง
  • ต่อมาข้อความคอมมิตมีใจความว่า “เนื่องจากการเปลี่ยนไลเซนส์ จะไม่มีการอัปเดตเวอร์ชันใน homebrew-core อีก จึงจะเลิกใช้งาน formula นี้และเพิ่มคำเตือน”

ลำดับการรีวิวและการสะท้อนการเปลี่ยนแปลง

  • PR ถูกเปิดเมื่อวันที่ 14 สิงหาคม 2023 และมี maintainer หลายคนรีวิวการเปลี่ยนแปลงใน Formula/terraform.rb
  • วันที่ 6 กันยายน 2023 มีการ ping เพื่อขอให้สะท้อนฟีดแบ็กจากการรีวิว และผู้เขียนแจ้งว่าได้ดำเนินการแล้ว
  • วันที่ 7 กันยายน 2023 MikeMcQuaid อนุมัติการเปลี่ยนแปลง แต่ถูกนำออกจาก merge queue เพราะการตรวจสอบสถานะล้มเหลว
  • วันที่ 20 กันยายน 2023 chenrui333 ก็อนุมัติการเปลี่ยนแปลงเช่นกัน
  • วันที่ 23 กุมภาพันธ์ 2024 PR ถูกทำเครื่องหมายเป็น draft

การจัดการ dependency และ PR ที่เกี่ยวข้อง

  • วันที่ 13 มีนาคม 2024 มีคอมมิต cdktf: deprecate ที่อ้างถึง PR นี้
    • ข้อความคอมมิตนั้นระบุว่า cdktf ใช้ terraform ที่กำลังจะถูกเลิกใช้งาน
    • อธิบายว่าเป็นหนึ่งใน formula สุดท้ายที่ขัดขวางการเลิกใช้งาน terraform
    • ระบุว่า cdktf มียอดดาวน์โหลดมากกว่า 700 ครั้งต่อเดือน และแม้จะโฮสต์อยู่ใน HashiCorp GitHub org ก็ไม่ได้รับผลจากการเปลี่ยนไลเซนส์ BUSL
  • PR ที่เกี่ยวข้องคือ cdktf: deprecate #166001 ซึ่งถูกรวมแล้ว
  • วันที่ 3 เมษายน 2024 atlantis: vendor terraform #167948 ก็อ้างถึง PR นี้และถูกรวมแล้ว

สรุปสุดท้ายและการรวมโค้ด

  • วันที่ 4 เมษายน 2024 ผู้เขียนแจ้งว่า “จัดการ dependency ทั้งหมดแล้ว ตอนนี้โอเคแล้ว” และเปลี่ยน PR กลับเป็นสถานะพร้อมรีวิว
  • p-linnane ให้ฟีดแบ็กว่าสถานการณ์ดังกล่าวเกิดขึ้นแล้ว จึงสามารถลบ ถ้อยคำแบบอนาคตกาล ออกได้
  • ผู้เขียนสะท้อนฟีดแบ็กนั้น และอัปเดตสาขาด้วยคอมมิต terraform: deprecate and add caveat 1c7b99b
  • p-linnane, MikeMcQuaid และ chenrui333 อนุมัติการเปลี่ยนแปลงสุดท้าย
  • วันที่ 5 เมษายน 2024 PR ถูกรวมเข้า Homebrew master ผ่าน merge queue ด้วยคอมมิต 4782218
  • ในวันเดียวกัน terraform: deprecate and add caveat #168090 ก็ถูกอ้างถึงในฐานะ PR ที่ถูกรวมแล้ว

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

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

 
GN⁺ 2023-10-09
ความคิดเห็นใน Hacker News

  • จุดสำคัญคือยังพักไว้ก่อน ไม่ได้เลิกใช้แพ็กเกจที่พึ่งพาทันที เพื่อดูว่า สามารถเปลี่ยนไปใช้ตัวทดแทนได้หรือไม่
    เช่น โปรแกรมที่พึ่งพา Terraform มีความเป็นไปได้สูงที่จะใช้ OpenTofu เป็นตัวทดแทนได้
    น่าเสียดายที่ Vault, Consul, Nomad ดูไม่น่าจะมีทางเลือกโอเพนซอร์สเกิดขึ้น โดยเฉพาะ Nomad เคยเป็นผลิตภัณฑ์ที่ดีจนกว่า HashiCorp จะหยุดลงทุน แต่ตอนนี้เมื่อกลายเป็นซอร์สปิดแล้ว โอกาสที่จะมีคนนำไปใช้ก็ดูแทบไม่มี จนออกจะน่าขำด้วยซ้ำ

    • ถ้ามีใครเริ่มทำ public fork ของ Vault ก็อยากช่วย contribute เท่าที่มีเวลา
      เพิ่มเติม: https://github.com/hashicorp/vault/graphs/contributors?from=...
    • ค่อนข้างชอบ Nomad มาก มันเบากว่า k3s ด้วยซ้ำ และเหมาะกับ โปรเจกต์งบต่ำ ของผมมาก
      เห็นทิศทางแบบนี้แล้วก็เสียดายนิดหน่อย
    • เป้าหมายของ Nomad ที่จะรันทุกอย่างในโลกนั้นเกินตัวไป สุดท้ายก็ไม่แพร่หลาย และถ้าจะตั้งค่าก็ยังต้องใช้ Consul ด้วย
      Docker Swarm เป็นทางออกที่เรียบง่ายกว่าและดีกว่า Nomad อีกทั้งยังฝังอยู่ใน Docker Engine เอง
    • พูดตรง ๆ ผลิตภัณฑ์ของ HashiCorp โดยรวมดีมากจริง ๆ เพียงแต่ผมมองว่าพวกเขาเจอกับ อาการขยับเร็วเกินไป
      บริษัทเร่งเข้าตลาดหุ้น และข้อบกพร่องส่วนใหญ่ในช่วงหลัง ๆ สามารถย้อนกลับไปถึงความพยายามผลักดันราคาหุ้นให้สูงขึ้นได้
      HashiCorp ยุคแรกยอดเยี่ยมมาก เป็นผู้พิทักษ์โอเพนซอร์ส และดูเหมือน Red Hat หรือ Canonical หน้าใหม่ที่กำลังเติบโต ผลิตภัณฑ์ล้ำสมัยและเพิ่มคุณค่ามหาศาลให้กับระบบนิเวศโอเพนซอร์ส แต่เมื่อ Terraform ดังมาก ก็ทำให้ผลิตภัณฑ์อื่นได้รับความสนใจตามไปด้วย และบริษัทก็มีชื่อเสียงเกินไป
      หลังเข้าตลาดหุ้น ภาพที่ชัดเจนคือพยายามเอาเงินและลูกค้าองค์กรให้ได้ไม่ว่าจะต้องแลกด้วยอะไรก็ตาม
      Terraform เองหลังเวอร์ชัน 1 ก็รู้สึกเหมือนอยู่ในโหมดบำรุงรักษา Terraform provider พังบ่อย และผมคิดว่าในสภาพแวดล้อม production ควร pin provider ลงไปถึงระดับ patch version ช่วงไม่กี่ปีมานี้ แม้แต่การอัปเดต patch เล็ก ๆ ก็มีปัญหาหลายครั้ง พวกเขายังขึ้นชื่อว่าเริ่มปฏิเสธ contribution โอเพนซอร์สที่ไม่มีคุณค่าทางธุรกิจต่อ HashiCorp ด้วย หลัง Terraform ไปถึง v1 ดูเหมือนความสนใจแทบทั้งหมดจะถูกเทไปที่ Terraform Cloud และ Terraform Enterprise ใน HashiConf ทุก talk ให้ความรู้สึกเหมือนโฆษณาชวนเชื่อเพื่อดันผลิตภัณฑ์เหล่านี้ และตอนนี้ก็ดูเหมือนจะสนใจแค่นั้น
      Nomad เคยเป็นผลิตภัณฑ์ที่ HashiCorp คาดหวังมากอยู่ช่วงหนึ่ง แต่ดูเหมือนถูกทิ้งไว้ข้างทางระหว่างการไล่ยึดตลาดองค์กร คงเป็นหลังจากพบว่าองค์กรส่วนใหญ่ทุ่มไปที่ Kubernetes และ Nomad มีประโยชน์กับสตาร์ทอัพที่เคลื่อนไหวเร็วมากกว่า
      Vault เป็นเครื่องมือที่ยอดเยี่ยม โดยเฉพาะในฝั่งโอเพนซอร์ส แต่ช่วงไม่กี่ปีที่ผ่านมา พวกเขาแยก Vault เวอร์ชันโอเพนซอร์สกับเวอร์ชันมีไลเซนส์ออกจากกันอย่างมาก และเวอร์ชันโอเพนซอร์สก็เริ่มให้ความรู้สึกเหมือนเป็นภาระสำหรับ HashiCorp ปีที่แล้วตอนบริษัทผมพิจารณาย้ายมาใช้ Vault อย่างจริงจังและคุยกับ HashiCorp พวกเขาปฏิบัติต่อโซลูชันโอเพนซอร์สแบบ self-hosted เหมือนเป็นรุ่นทดลองของ “Vault ตัวจริง” และมันก็รู้สึกแบบนั้นจริง ๆ แทบทุกปัญหาที่เจอระหว่างตั้งค่า พวกเขาตอบทำนองว่า “ในเวอร์ชัน Enterprise จะไม่มีปัญหา”
      โดยรวมแล้วพวกเขาถอยกลับไปเหลือแค่ความพยายามขั้นต่ำที่จำเป็นต่อการรองรับเวอร์ชันโอเพนซอร์สของผลิตภัณฑ์ และเป็นบริษัทที่มุ่งองค์กรเต็มตัวมาสักพักแล้ว ต้องหาเงินก็เลยจะโทษอย่างเดียวไม่ได้ แต่ก็อดนึกถึง Red Hat กับ Canonical ในฐานะตัวอย่างของสิ่งที่ HashiCorp อาจเป็นได้ไม่ได้
      ตอนนี้รู้สึกเหมือนพ่อแม่ที่มองดูลูกไม่สามารถใช้ศักยภาพของตัวเองได้เต็มที่ ส่วนใหญ่ดูเหมือนเป็นเพราะความโลภหรือความทะเยอทะยานที่มากเกินไป เมื่อคิดถึง HashiCorp คำว่า “ไม่ได้โกรธ แค่ผิดหวัง” ก็ผุดขึ้นมา หวังว่า OpenTofu จะมาเติมช่องว่างของ Terraform ได้ ส่วน Vault นั้นเลยจุดนั้นไปแล้ว และเราใช้เครื่องมือจัดการ secret ของผู้ให้บริการคลาวด์รายใหญ่แทน ถูกใจน้อยกว่ามาก แต่ถูกกว่าและซับซ้อนน้อยกว่า ใช้ Kubernetes แทน Nomad ซึ่งก็โอเคเพราะมันกลายเป็นมาตรฐานไปแล้ว ผมคงอยู่ได้ดี แต่ผิดหวังกับ HashiCorp
    • Nomad กลายเป็น ซอร์สปิด จริง ๆ แล้วเหรอ?

  • HashiCorp ดูแล tap ของตัวเอง
    https://github.com/hashicorp/homebrew-tap
    https://www.hashicorp.com/blog/announcing-hashicorp-homebrew...

    • สำหรับข้อมูลเพิ่มเติม เวอร์ชันที่ Homebrew เป็นเจ้าของจะ บิลด์สิ่งเหล่านี้ใหม่จากซอร์ส: https://github.com/Homebrew/homebrew-core/pull/139538/files#...
      ใน ecosystem การทำแพ็กเกจของ Linux ก็มักใช้วิธีนี้เช่นกัน แต่โดยทั่วไปจะจัดการเรื่องการแพ็กเกจ dependency อย่างชัดเจนไปด้วย อาจเป็นเพราะเหตุนี้ Vault และตัวอื่น ๆ จึงอาจไม่ได้เข้าไปอยู่ในชุดแพ็กเกจของ distro แม้ก่อนการเปลี่ยนไลเซนส์
      ส่วนแบบของ HashiCorp จะคัดลอก release build: https://github.com/hashicorp/homebrew-tap/blob/master/Formul...

  • ทำไมถึงเป็นแบบนั้น? Homebrew ก็เป็นแค่ ตัวจัดการแพ็กเกจ ไม่ใช่หรือ? ไม่เข้าใจว่าทำไมไลเซนส์ที่ไม่เสรีจึงต้องจำกัดการรวมเครื่องมือของ HashiCorp
    หรือว่ามีนโยบายว่ารวมได้เฉพาะซอฟต์แวร์เสรีเท่านั้น
    แก้ไข: จริง ๆ แล้วมีแนวทางที่ค่อนข้างเข้มงวด: https://docs.brew.sh/License-Guidelines

    • Homebrew มีนโยบายว่า รวมเฉพาะซอฟต์แวร์เสรี [1]
      “จะรับเข้า homebrew/core เฉพาะ formula ที่ใช้ไลเซนส์ตาม Debian Free Software Guidelines หรือเผยแพร่เป็นสาธารณสมบัติตามแนวทางซอฟต์แวร์สาธารณสมบัติของ DFSG”
      [1]: https://docs.brew.sh/License-Guidelines
    • Homebrew ไม่ได้เป็นแค่ตัวจัดการแพ็กเกจอย่างเดียว
      มันเป็นทั้งซอฟต์แวร์ที่ชื่อ brew หรือก็คือตัวจัดการแพ็กเกจ และยังเป็น คลังแพ็กเกจ homebrew-core ที่เชื่อมต่อให้โดยค่าเริ่มต้นด้วย คลังแพ็กเกจนี้ถูกดูแลอย่างรอบคอบและรับเฉพาะไลเซนส์โอเพนซอร์สเท่านั้น
      คุณมีอิสระที่จะ tap คลังที่ต้องการด้วย brew แต่ PR นี้พูดถึงเฉพาะคลัง core เท่านั้น
    • เรื่องนี้ถูกแค่บางส่วน
      โดยค่าเริ่มต้น Homebrew รองรับสองคลังคือ homebrew/core และ homebrew/casks หรือในศัพท์ของ Homebrew คือ tap ไว้
      Core รับเฉพาะซอฟต์แวร์เสรี โดยนักพัฒนา Homebrew จะ build เอง และติดตั้งไว้ในที่อย่าง /opt/homebrew ส่วน Casks รับแทบทุกอย่าง รวมถึงซอฟต์แวร์เชิงพาณิชย์และซอฟต์แวร์ที่ไม่มีซอร์สโค้ด ซอฟต์แวร์แบบนี้โดยมากจะดาวน์โหลดตรงจากฝั่งผู้พัฒนาและติดตั้งไปยังตำแหน่งที่ต้องการ ซึ่งมักเป็น /Applications

  • ผมชอบบริการที่ Homebrew มีให้ แต่ Terraform เป็นหนึ่งในกรณียกเว้นที่ ควรจัดการนอก brew มากกว่า ตอนนี้ผมมองว่า tf-switch เป็นตัวเลือกที่ได้รับความนิยมที่สุด
    Terraform มักต้องตรึงเวอร์ชันเฉพาะ เพราะถ้าเผลออัปเดต state file อาจเป็นอันตรายได้ แน่นอนว่าการอัปเดต Terraform ปวดหัวน้อยลงกว่าเมื่อเทียบกับยุคก่อน 1.0 มากแล้ว

    • ผมใช้ rtx หรือก็คือ rust asdf https://github.com/jdx/rtx สามารถติดตั้งภาษาต่าง ๆ ด้วยเครื่องมือเดียว และจัดการ ตัวแปรสภาพแวดล้อมของโปรเจกต์ แบบ direnv ได้ด้วย
    • ใช่เลย ทางที่ดีที่สุดคือ จัดการใน MacPorts ซึ่งติดตั้งแพ็กเกจเวอร์ชันเฉพาะและสลับเวอร์ชันได้ง่าย
    • ถ้าต้องติดตั้ง Terraform หลายเวอร์ชัน ก็ใช้ tfenv ผ่าน Homebrew ได้เช่นกัน

  • ย้ายไปอยู่ใน cask แทนก็ได้ ในทางปฏิบัติไม่ได้กระทบมากนัก

    • ใช่ ถ้า HashiCorp ยังอยากแจกจ่ายผ่าน Homebrew ต่อ cask ก็เพียงพอแล้ว แต่คิดว่าไม่น่าจะเป็นแบบนั้น หลายปีที่ผ่านมาเขาแนะนำให้ ติดตั้งไบนารีโดยตรง จากเซิร์ฟเวอร์อยู่แล้ว และเอกสารการติดตั้ง Terraform ก็ใช้วิธีนั้นมาพักหนึ่งแล้ว
      ผลกระทบที่ใหญ่กว่าคือกับเครื่องมืออื่น ๆ ที่พึ่งพา Terraform อย่างที่เห็นตรงนี้: https://github.com/Homebrew/homebrew-core/pull/139538#pullre...
      เครื่องมืออย่าง atlantis และ infracost ก็พึ่งพา Terraform จึงกำลังถูกนำออกด้วย ดังนั้นการแจกจ่ายเครื่องมือเล็ก ๆ เหล่านั้นจะยากขึ้นอีกเล็กน้อย โชคดีที่ในเธรดนั้นบอกว่าจะระงับไว้ก่อน เพื่อให้เมื่อ OpenTofu เสถียรแล้วสามารถเปลี่ยน dependency ไปเป็นตัวแทนหรือเอาออกไปเลยได้ แต่ผมคิดว่าผลกระทบจริง ๆ อยู่ที่ เครื่องมือแวดล้อม เหล่านี้

  • Homebrew มีประโยชน์มากจริง ๆ แต่ก็มีการตัดสินใจด้านการออกแบบที่แปลกอยู่ ทำไมต้องติดตั้ง Python เฉพาะตัวใหม่? แล้วทำไม Python ตัวนั้นต้องเป็นเวอร์ชันล่าสุดด้วย?
    แต่พอแต่ละ formula ต้องระบุเวอร์ชัน Python เอง ในความเป็นจริงมันก็ไม่ได้เป็นเวอร์ชันล่าสุดเสมอไป และก็เกิด formula ที่ระบุสารพัดเวอร์ชันขึ้นมา ไม่เข้าใจว่าทำไมไม่ใช้ Python ของระบบ เหมือนตัวจัดการแพ็กเกจอื่น ๆ ในเครื่องมี Python ที่ติดตั้งไว้เยอะเกินไปแล้ว ไม่ต้องการเพิ่มอีกตัว โดยเฉพาะเวลาต้องติดตั้งแพ็กเกจ pip เพื่อให้บางอย่างทำงานได้ถูกต้อง ยิ่งชวนสับสน

    • ไม่ได้จะปกป้องตัวเลือกที่แปลกที่สุดหรอก แต่ถ้าใช้ Python ของระบบ ปกติมักจะมีปัญหามากกว่า ตอนนี้ macOS ไม่มี Python ของระบบแล้ว
      ใช้แบบนี้ได้:
      pythonX.Y -m pip install foo
      ถ้าอยากตัดความกำกวมก็ใช้ alias ได้ สำหรับโปรเจกต์งาน ใช้ pyenv กับ virtual environment จะดี

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

    • formula ที่ไม่ได้อัปเดตเพราะ upstream ไม่ออกเวอร์ชันใหม่ กับ formula ที่ Homebrew รับอัปเดตใหม่ไม่ได้เพราะไลเซนส์ไม่ใช่โอเพนซอร์สอีกต่อไป เป็นคนละเรื่องกัน
      ส่วนของ Homebrew ที่ไม่ใช่ Cask ต้องการไลเซนส์โอเพนซอร์ส และกรณีนี้เป็นอย่างหลัง
    • ไม่เกี่ยวกับว่าแพ็กเกจตายแล้วหรือไม่ ผู้ใช้คาดเดาได้ว่า Homebrew จะไม่เสกอัปเดตที่ upstream ไม่มีขึ้นมาให้
      ในทางกลับกัน ถ้ามีอัปเดตอยู่จริงแต่ Homebrew แจกจ่ายไม่ได้ตามกฎหมาย จนอาจทำให้ผู้ใช้ติดตั้งเวอร์ชันเก่าและมีช่องโหว่ได้ ก็ควรเตือนผู้ใช้
    • Homebrew Core มีเฉพาะแอปที่ใช้ไลเซนส์โอเพนซอร์ส โดยเฉพาะไลเซนส์ที่เข้ากันได้กับ Debian Free Software Guidelines เช่น GPL, Apache, BSD, MIT เป็นต้น
      https://wiki.debian.org/DFSGLicenses#DFSG-compatible_License...