Homebrew ने HashiCorp के लिए चेतावनी जोड़ी, deprecate करने की तैयारी

 (github.com/Homebrew)
1 पॉइंट द्वारा GN⁺ 2023-10-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Homebrew/homebrew-core PR #139538, HashiCorp के license change की वजह से terraform formula में user warning जोड़ने और भविष्य में इसे disable किया जा सकने की सूचना देने वाला बदलाव है
  • इस बदलाव की वजह यह है कि license change के बाद homebrew-core में terraform के version updates अब नहीं होंगे, और फोकस इस बात पर है कि install करते समय users इसे समझ लें
  • review के दौरान version exception पर चर्चा हुई कि 1.6.0 से पहले की future releases स्वीकार की जा सकती हैं, हालांकि ऐसी releases न भी हों, यह भी कहा गया
  • dependencies साफ़ करने के बाद PR 4 अप्रैल 2024 को फिर से review-ready हुआ, और future tense वाले वाक्य हटाने की feedback के अनुसार terraform: deprecate and add caveat commit के साथ update किया गया
  • अंतिम बदलाव 5 अप्रैल 2024 को merge queue के जरिए Homebrew master में commit 4782218 के रूप में merge हुआ, और संबंधित terraform deprecation PR #168090 भी merge हुआ

terraform formula को deprecate करना और warning जोड़ना

  • PR #139538 का उद्देश्य users को यह बताना था कि HashiCorp के license change की वजह से homebrew-core में terraform version updates अब नहीं होंगे
  • शुरुआती विवरण का रुख users को यह बताने का था कि “किसी समय इस formula को disable किया जा सकता है”
  • बदलाव का target Formula/terraform.rb था, और बाद में file path Formula/t/terraform.rb के रूप में दिखाया गया
  • PR पर formula deprecated, busl-license, go, maintainer feedback जैसे labels लगे थे

version और license से जुड़ी चर्चा

  • review के दौरान यह राय आई कि terraform की future releases में 1.6.0 से पहले के versions स्वीकार किए जा सकते हैं
    • लेकिन साथ ही यह भी कहा गया कि ऐसी releases वास्तव में न भी हों
  • PR विवरण ने license change के बाद homebrew-core में अब version updates न होने को इस बदलाव का आधार बताया
  • बाद के commit message में यह बात थी कि “license change की वजह से homebrew-core में अब version updates नहीं होंगे, इसलिए किसी समय इस formula को disable किया जाएगा”

review और बदलाव लागू होने की प्रक्रिया

  • 14 अगस्त 2023 को PR खोला गया, और कई maintainers ने Formula/terraform.rb में बदलाव की review की
  • 6 सितंबर 2023 को review feedback लागू करने के लिए ping किया गया, और author ने बताया कि बदलाव कर दिए गए हैं
  • 7 सितंबर 2023 को MikeMcQuaid ने बदलाव approve किया, लेकिन merge queue में status checks fail होने से इसे हटा दिया गया
  • 20 सितंबर 2023 को chenrui333 ने भी बदलाव approve किया
  • 23 फ़रवरी 2024 को PR को draft के रूप में चिह्नित किया गया

dependencies की सफ़ाई और संबंधित PRs

  • 13 मार्च 2024 को cdktf: deprecate commit ने इस PR का संदर्भ दिया
    • उस commit message में कहा गया कि cdktf जल्द deprecate होने वाले terraform का उपयोग करता है
    • इसे terraform deprecation को रोकने वाले आख़िरी formulae में से एक बताया गया
    • यह भी लिखा गया कि cdktf के हर महीने 700 से अधिक downloads हैं, और HashiCorp GitHub org पर hosted होने के बावजूद यह BUSL license change से प्रभावित नहीं है
  • संबंधित PR cdktf: deprecate #166001 merge किया गया
  • 3 अप्रैल 2024 को atlantis: vendor terraform #167948 ने इस PR का संदर्भ दिया और वह भी merge हुआ

अंतिम चरण और merge

  • 4 अप्रैल 2024 को author ने बताया कि “सभी dependencies संभाल ली गई हैं, इसलिए अब ठीक है” और PR को review ready में बदल दिया
  • p-linnane ने feedback दिया कि यह स्थिति पहले ही हो चुकी है, इसलिए future tense वाले expressions हटाए जा सकते हैं
  • author ने यह लागू किया और branch को terraform: deprecate and add caveat commit 1c7b99b के साथ update किया
  • p-linnane, MikeMcQuaid, chenrui333 ने अंतिम बदलाव approve किए
  • 5 अप्रैल 2024 को PR merge queue के जरिए Homebrew master में commit 4782218 के रूप में merge हुआ
  • उसी दिन terraform: deprecate and add caveat #168090 को भी merged PR के रूप में संदर्भित किया गया

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-10-09
Hacker News की राय

  • अहम बात यह है कि dependent packages को तुरंत deprecate नहीं किया जा रहा, बल्कि यह देखने के लिए hold पर रखा गया है कि क्या उन्हें विकल्पों से बदला जा सकता है
    उदाहरण के लिए Terraform पर निर्भर programs में OpenTofu को विकल्प के तौर पर इस्तेमाल किए जाने की अच्छी संभावना है
    अफसोस, Vault, Consul, Nomad के लिए open source alternatives आने की संभावना नहीं दिखती। खासकर Nomad, HashiCorp के निवेश बंद करने से पहले तक अच्छा product था, लेकिन अब जब वह closed source हो गया है, तो उसके अपनाए जाने की संभावना लगभग नहीं दिखती—यह बात थोड़ी हास्यास्पद भी लगती है

    • अगर कोई Vault का public fork शुरू करे, तो समय मिलने पर मैं contribute करना चाहूंगा
      अपडेट: https://github.com/hashicorp/vault/graphs/contributors?from=...
    • मुझे Nomad काफी पसंद है। यह k3s से भी ज्यादा हल्का है, और मेरे कम बजट वाले projects के लिए बहुत अच्छी तरह fit बैठता था
      चीजें जिस दिशा में जा रही हैं, उसे देखकर थोड़ा अफसोस होता है
    • Nomad का लक्ष्य दुनिया की हर चीज चलाने का था, जो बहुत ज्यादा ambitious था। आखिरकार यह व्यापक रूप से स्थापित नहीं हो पाया, और इसे set up करने के लिए Consul भी चाहिए था
      Docker Swarm, Nomad से सरल और बेहतर समाधान है और Docker Engine में ही built-in है
    • सच कहूं तो HashiCorp products कुल मिलाकर वाकई अच्छे हैं। बस मुझे लगता है कि वे बहुत तेजी से आगे बढ़ने के syndrome से गुजरे
      उन्होंने listing/IPO को push किया, और हाल की ज्यादातर खामियों की जड़ें share price बढ़ाने की कोशिशों तक जाती हैं
      शुरुआती HashiCorp शानदार था। वह open source का रक्षक था, और उभरते हुए Red Hat या Canonical जैसा दिखता था। Products pathbreaking थे और open source ecosystem में भारी value जोड़ते थे। लेकिन Terraform के बहुत popular होने के साथ बाकी products पर भी ध्यान गया, और company बहुत ज्यादा मशहूर हो गई
      listing के बाद से, किसी भी कीमत पर पैसा और enterprise customers हासिल करने की कोशिश साफ दिखने लगी
      Terraform खुद भी version 1 के बाद से maintenance mode जैसा महसूस होता है। Terraform provider अक्सर टूट जाते हैं, और production environment में मेरा मानना है कि providers को patch version तक pin करना चाहिए। हाल के वर्षों में छोटी patch updates में भी कई बार समस्याएं आई हैं। HashiCorp इस बात के लिए भी जाना जाने लगा कि वह उन open source contributions को reject करने लगा जिनमें उसके लिए business value नहीं थी। Terraform के v1 पर पहुंचने के बाद से लगभग सारा ध्यान Terraform Cloud और Terraform Enterprise पर चला गया लगता है। HashiConf में हर presentation इन products को push करने वाला propaganda जैसा लगता है, और अब लगता है उन्हें बस इसी की परवाह है
      Nomad कभी कुछ समय तक HashiCorp का बहुत उम्मीदों वाला product था, लेकिन enterprise market पर कब्जा करने की कोशिश में लगता है उसे रास्ते में छोड़ दिया गया। शायद तब, जब उन्हें पता चला कि ज्यादातर enterprises Kubernetes पर पूरी तरह दांव लगा चुके हैं और Nomad तेज-moving startups के लिए ज्यादा उपयोगी है
      Vault खासकर open source क्षेत्र में एक शानदार tool था। लेकिन पिछले कुछ वर्षों में Vault के open source version और licensed version को काफी अलग कर दिया गया, और open source version HashiCorp को बोझ जैसा लगने लगा। पिछले साल हमारी company में Vault migration को गंभीरता से देखते समय जब हमने HashiCorp से बात की, तो उन्होंने open source self-hosted solution को “real Vault” के trial version जैसा treat किया, और असल में वैसा ही महसूस हुआ। Setup के दौरान आई लगभग हर समस्या पर उनका जवाब कुछ ऐसा था कि “enterprise version में यह ठीक है”
      कुल मिलाकर वे product के open source version को support करने के लिए जरूरी न्यूनतम effort ही छोड़कर पीछे हट गए, और काफी समय से पूरी तरह enterprise-focused company रहे हैं। पैसा कमाना जरूरी है, इसलिए सिर्फ दोष नहीं दे सकता, लेकिन HashiCorp क्या बन सकता था—इसके उदाहरण के तौर पर Red Hat और Canonical याद आए बिना नहीं रहते
      अब ऐसा लगता है जैसे कोई parent अपने बच्चे को उसकी पूरी potential तक न पहुंचते देख रहा हो। वजह ज्यादातर greed या excessive ambition लगती है। HashiCorp के बारे में सोचता हूं तो “गुस्सा नहीं हूं, बस निराश हूं” वाली बात याद आती है। उम्मीद है OpenTofu, Terraform की खाली जगह भर देगा। Vault के मामले में हम आगे बढ़ चुके हैं और बड़े cloud providers के secrets management tools इस्तेमाल कर रहे हैं। वे मुझे बहुत कम पसंद हैं, लेकिन सस्ते और कम complex हैं। Nomad की जगह Kubernetes इस्तेमाल कर रहा हूं, और चूंकि वह standard बन चुका है, इसलिए ठीक है। मैं तो ठीक रहूंगा, लेकिन HashiCorp से निराश हूं
    • क्या Nomad सच में closed source हो गया है?

  • HashiCorp अपना खुद का tap maintain करता है
    https://github.com/hashicorp/homebrew-tap
    https://www.hashicorp.com/blog/announcing-hashicorp-homebrew...

    • संदर्भ के लिए, Homebrew के स्वामित्व वाला version इन्हें source से फिर build करता है: https://github.com/Homebrew/homebrew-core/pull/139538/files#...
      Linux packaging ecosystem में भी आम तौर पर यही तरीका होता है, लेकिन वहां dependency packaging को भी आमतौर पर स्पष्ट रूप से साथ में handle किया जाता है। शायद इसी वजह से license change से पहले भी Vault वगैरह distro package collections में नहीं आ पाए होंगे
      HashiCorp वाला variant release build को copy करता है: https://github.com/hashicorp/homebrew-tap/blob/master/Formul...

  • ऐसा क्यों? Homebrew तो बस एक package manager नहीं है? समझ नहीं आ रहा कि non-free license की वजह से HashiCorp tools को शामिल करना क्यों सीमित होना चाहिए
    या फिर क्या इसकी कोई policy है कि इसमें सिर्फ free software ही शामिल होगा
    सुधार: असल में इसके काफी सख्त guidelines हैं: https://docs.brew.sh/License-Guidelines

    • Homebrew की policy है कि इसमें सिर्फ free software शामिल होता है [1]
      “homebrew/core में सिर्फ वे formula स्वीकार किए जाते हैं जो Debian Free Software Guidelines license का इस्तेमाल करते हैं, या DFSG के public domain software guidelines के तहत public domain में जारी किए गए हैं”
      [1]: https://docs.brew.sh/License-Guidelines
    • Homebrew सिर्फ एक package manager भर नहीं है
      यह brew नाम का software, यानी package manager भी है, लेकिन साथ ही default रूप से जुड़ा हुआ homebrew-core package repository भी है। यह package repository सावधानी से manage किया जाता है और केवल open source licenses स्वीकार करता है
      आप चाहें तो किसी भी repository को brew से tap करके इस्तेमाल कर सकते हैं, लेकिन यह PR सिर्फ core repository से संबंधित है
    • यह बात आंशिक रूप से ही सही है
      Default रूप से Homebrew दो repositories, homebrew/core और homebrew/casks, को support करता है, यानी Homebrew की terminology में उन्हें tap करता है
      Core केवल free software स्वीकार करता है, जिसे Homebrew developers खुद build करते हैं और /opt/homebrew वगैरह में install किया जाता है। Casks commercial software और source code के बिना वाले software तक, लगभग कुछ भी स्वीकार करता है। ऐसा software आम तौर पर developer की तरफ से सीधे download होकर मनचाही जगह, आमतौर पर /Applications में install होता है

  • Homebrew जो service देता है वह अच्छी है, लेकिन Terraform उन exceptional cases में से एक है जिसे brew के बाहर manage करना बेहतर है। अभी मेरे हिसाब से tf-switch सबसे popular option है
    Terraform में अगर गलती से state file update हो जाए तो जोखिम हो सकता है, इसलिए कई बार किसी specific version को pin करना पड़ता है। बेशक 1.0 से पहले वाले समय की तुलना में Terraform updates अब काफी कम सिरदर्द हैं

    • मैं rtx, यानी rust asdf https://github.com/jdx/rtx इस्तेमाल करता हूं। इससे languages को एक ही tool से install किया जा सकता है, और direnv जैसे project environment variables भी handle किए जा सकते हैं
    • सही। specific version packages install करने और आसानी से switch करने के लिए MacPorts के अंदर manage करना सबसे अच्छा है
    • कई Terraform versions install करने के लिए tfenv भी Homebrew में इस्तेमाल किया जा सकता है

  • इसके बजाय इसे cask में रखा जा सकता है। Practical तौर पर इसका बहुत बड़ा असर नहीं है

    • सही। अगर HashiCorp Homebrew के जरिए distribute करना जारी रखना चाहता है, तो cask से भी यह पूरी तरह संभव है। हालांकि ऐसा होने की संभावना नहीं लगती। वे पिछले कुछ सालों से servers पर binaries सीधे install करने की सलाह देते रहे हैं, और Terraform installation docs में भी कुछ समय तक यही तरीका था
      ज्यादा बड़ा असर उन दूसरे tools पर है जो Terraform पर depend करते हैं, जैसा यहां दिख रहा है: https://github.com/Homebrew/homebrew-core/pull/139538#pullre...
      atlantis और infracost जैसे tools भी Terraform पर depend करते हैं, इसलिए उन्हें हटाया जा रहा है। इसलिए ऐसे छोटे tools का distribution थोड़ा और मुश्किल हो जाएगा। अच्छी बात यह है कि उस thread में कहा गया है कि OpenTofu stable होने पर dependency को replacement से बदलने या पूरी तरह हटाने तक इसे hold पर रखा जा रहा है। लेकिन मुझे लगता है कि असली असर इन्हीं surrounding tools पर है

  • Homebrew सच में उपयोगी है, लेकिन इसके कुछ अजीब design choices भी हैं। यह एक नया dedicated Python क्यों install करता है? और वह Python latest ही क्यों होना चाहिए?
    फिर भी हर formula को Python version specify करना पड़ता है, इसलिए असल में वह हमेशा latest भी नहीं रहता, और तरह-तरह के versions specify करने वाले formula बन जाते हैं। समझ नहीं आता कि यह बाकी package managers की तरह system Python क्यों नहीं इस्तेमाल करता। पहले से installed Python बहुत ज्यादा हैं, एक और की जरूरत नहीं है। खासकर तब यह और confusing होता है जब कुछ ठीक से चलाने के लिए pip package install करना पड़े

    • मैं सबसे अजीब choices तक का बचाव नहीं करना चाहता, लेकिन system Python इस्तेमाल करने से आम तौर पर समस्याएं ज्यादा हो जाती हैं। macOS में अब system Python नहीं है
      ऐसे इस्तेमाल करें:
      pythonX.Y -m pip install foo
      ambiguity हटानी हो तो alias भी इस्तेमाल कर सकते हैं। work projects के लिए pyenv और virtual environments इस्तेमाल करना बेहतर है

  • यह political decision जैसा दिखता है। Homebrew में ऐसे कई packages हैं जिन्हें अब updates नहीं मिलेंगे, लेकिन उन्हें deprecate नहीं किया जाता

    • ऐसी formula जिसे इसलिए update नहीं मिल रहा क्योंकि upstream नया version release नहीं कर रहा, और ऐसी formula जिसे इसलिए Homebrew में नए updates नहीं मिल सकते क्योंकि उसका license अब open source नहीं है—दोनों अलग बातें हैं
      Homebrew का non-Cask हिस्सा open source license मांगता है, और यह case बाद वाला है
    • यह package के dead होने से अलग है। Users यह expect कर सकते हैं कि upstream में मौजूद नहीं update Homebrew जादू से बना कर नहीं देगा
      इसके विपरीत, अगर updates मौजूद हैं लेकिन Homebrew उन्हें legal रूप से distribute नहीं कर सकता, और इससे पुराना व vulnerable version install हो सकता है, तो users को warn करना जरूरी है
    • Homebrew Core में सिर्फ open source license, खास तौर पर Debian Free Software Guidelines के compatible license वाले apps आते हैं। GPL, Apache, BSD, MIT आदि इसमें शामिल हैं
      https://wiki.debian.org/DFSGLicenses#DFSG-compatible_License...