Homebrew 6.0.0 रिलीज़

• सभी metadata को एक single download में बांधने वाली internal JSON API अब default हो गई है, जिससे updates तेज़ होते हैं और network communication कम होता है
  • पहले की HOMEBREW_USE_INTERNAL_API opt-in variable को deprecated किया गया है
• Linux पर Bubblewrap sandbox लागू किया गया है, जिससे build·test·postinstall चरणों को macOS की तरह isolate करके चलाया जाता है
• user survey के आधार पर ask mode अब developers के लिए default बन गया है, और brew install·brew upgrade के समय dependency summary और confirmation prompt दिखता है
• brew bundle में parallel formula installation अब default रूप से अपने-आप चलती है, साथ ही npm·krew extensions और Windows winget support जोड़ा गया है
• brew leaves में लगभग 30% speedup समेत startup और upgrade के पूरे flow में performance improvements
• macOS 27 (Golden Gate) के लिए शुरुआती support जोड़ा गया
  • Intel support बंद होने के अनुसार, सितंबर 2026 में macOS Intel x86_64 को Tier 3 में रखा जाएगा, और सितंबर 2027 में पूरी तरह unsupported हो जाएगा
• 3 security advisories सार्वजनिक किए गए और ठीक किए गए हैं (HTTPS→HTTP redirect bypass, .pkg postinstall root code execution, /var/tmp plist ownership hijack)
• npx जैसे नए command brew exec और installed packages की vulnerability जांचने वाला brew vulns समेत नए commands जोड़े गए
• common postinstall और flight behavior को literal DSL data के रूप में JSON API में expose करने वाला install steps framework पेश किया गया है, जिससे simple tasks के लिए Ruby files को download और evaluate करने की ज़रूरत नहीं रहती
• npm·PyPI जैसे high-risk ecosystems पर download cooldown लागू किया गया है ताकि upstream supply-side security risks कम किए जा सकें

[lamanus]

Intel Mac तक सपोर्ट जारी रखने के लिए संसाधन भी कम हैं, और GitHub Actions भी अब इमेज उपलब्ध कराने वाला नहीं है, इसलिए Homebrew के पास भी इसके मुताबिक आगे बढ़ने के अलावा कोई विकल्प नहीं है.

[GN⁺]

Hacker News की राय

• मैं GitHub का @bfontaine हूँ। मैंने 2014~2016 के आसपास Homebrew मेंटेनेंस में मदद की थी, और Mike को 16 साल से भी ज़्यादा समय तक इसे मेंटेन करते हुए और अब भी नए फीचर जारी करते देखना हमेशा हैरान करता है

  • सितंबर में 17 साल हो जाएंगे। उस समय बेहतरीन योगदान के लिए धन्यवाद, और आशा है आप अच्छे होंगे
  • Homebrew इतना पसंद है कि जहाँ संभव हो Linux पर भी इसका इस्तेमाल करता हूँ
    ज़्यादातर Linux package manager यूज़र द्वारा इंस्टॉल किए गए पैकेज और सिस्टम पैकेज को अलग नहीं कर पाते, इसलिए वर्कस्टेशन को साफ-सुथरा रखना लगभग असंभव हो जाता है और यह समझना मुश्किल होता है कि क्या हटाया जा सकता है
    ऊपर से, native package manager अक्सर Homebrew की तुलना में अपडेट में धीमे होते हैं, इसलिए कई बार सिर्फ पुराने पैकेज ही मिलते हैं

• प्रयोग के तौर पर मैंने Homebrew+pipx+npm से https://mise.jdx.dev/ पर पूरा OS-स्तरीय डेवलपमेंट एनवायरनमेंट शिफ्ट किया, और यह सच में बहुत अच्छी तरह काम कर रहा है
  कई टूल सीधे GitHub releases या संबंधित package manager (uv, pnpm, go get आदि) से इंस्टॉल हो जाते हैं, इसलिए repackaging के लिए glue code भी नहीं चाहिए और version lag भी नहीं होता
  आप मनचाहा version या एक साथ कई version इंस्टॉल कर सकते हैं, और हर working folder या environment के हिसाब से active version को dynamically बदल सकते हैं
  दिलचस्प बात यह है कि Mise dependencies को सपोर्ट नहीं करता, लेकिन ज़्यादातर मामलों में यह समस्या नहीं बनी। pnpm/uv इसे संभाल लेते हैं, या फिर static binary होने की वजह से चीज़ें वैसे ही चल जाती हैं
  पहले मैंने एक Python app को Homebrew के लिए package करते समय 50 dependencies को resources के रूप में लाया था, सबको source से build किया या मैन्युअली जाँचा कि वे Homebrew में हैं या नहीं, 5 भाषाओं के build toolchain को dependency के रूप में घोषित किया, हर अपडेट पर CI के लिए 1 घंटे से ज़्यादा इंतज़ार किया, और फिर upstream update की वजह से “build-time dependency loop” बन गया जिसे Homebrew में सुलझाया ही नहीं जा सका
  इसलिए मैं पूरी तरह समझता हूँ कि Mise ने “आसान रास्ता” क्यों चुना और language-specific package manager पर सीधे निर्भर क्यों किया
  Brewfile में जो चीज़ मैं replace नहीं कर पाया वह सिर्फ Colima से बात करने के लिए ज़रूरी Docker CLI थी, और cask के लिए अब भी Homebrew इस्तेमाल करता हूँ। डेवलपमेंट एनवायरनमेंट के साथ प्रयोग करने की सलाह दूँगा। आजकल बहुत से शानदार नए टूल हैं

  • Mise वाकई अपनी अलग श्रेणी का लगता है। जैसा मैंने और जगहों पर भी कहा है, यह aqua या asdf जैसे registry पर निर्भर करता है
    जो लोग Homebrew पैकेज के लिए Mise इस्तेमाल करना चाहते हैं, उनके लिए https://github.com/kennyg/mise-zerobrew है
  • PHP developer के नज़रिए से देखें तो Mise का सपोर्ट, Shivam Mathur द्वारा Homebrew के लिए किए गए PHP packaging की तुलना में काफ़ी कमज़ोर लगा
    ज़्यादातर प्रोजेक्ट वैसे भी Docker का इस्तेमाल करते हैं, और local PHP उन कामों के लिए रहता है जिनमें Docker की ज़रूरत नहीं होती, जैसे static analysis
    मेरे पास कुछ प्रोजेक्ट Nix भी इस्तेमाल करते हैं, और Nix बाकी सबको छोटा साबित कर देता है, लेकिन पूरा user experience git से भी ज़्यादा hostile है
  • अच्छा है कि आपका अनुभव अच्छा रहा, लेकिन व्यक्तिगत रूप से मैं Mise से वापस Brew पर लौट आया
    यह मेरी skill की कमी भी हो सकती है, लेकिन Mise में बहुत ज़्यादा पैकेज ऐसे थे जिनमें दिक्कतें आईं
  • मुझे Mise बहुत पसंद है, लेकिन मैं इसे सिर्फ project-specific tool management या JDK version जैसी चीज़ों के लिए इस्तेमाल करता हूँ
    मैंने इसे system-wide tools के लिए भी आज़माया, लेकिन Helix, NeoVim, RipGrep जैसे टूल, जिनमें लगभग latest होना काफ़ी है और exact version की चिंता नहीं होती, उनके लिए यह उतना उपयुक्त नहीं लगा
  • Mise कुछ हद तक dependencies को सपोर्ट करता है, लेकिन उस तरह नहीं जैसा दूसरे package manager में अपेक्षित होता है
    Mise में dependencies automatic नहीं हैं; सब कुछ मैन्युअली define करना पड़ता है। इसका मकसद parallel install की वजह से आने वाली ordering problems से बचना है। उदाहरण के लिए, अगर आप pipx:black इस्तेमाल करते हैं, तो Python installation पूरी होने तक इंतज़ार करना होगा। यही टूल का depends option है
    यह जानबूझकर किया गया design है। Mise को Homebrew या Nix जैसी complete bootstrap solution के रूप में नहीं, बल्कि मौजूदा सिस्टम के ऊपर बैठने वाली overlay के रूप में डिज़ाइन किया गया है
    इसलिए आप Python को Brew से और black को Mise से मैनेज करें, तब भी यह लगभग बिना अलग configuration के काम करता है। मेरे हिसाब से यह design decision काफ़ी सफल रहा है। यह कमी जैसा लग सकता है, लेकिन शायद यही सबसे बड़ा कारण है कि यूज़र Mise को आसान महसूस करते हैं

• Homebrew immutable Linux distributions पर environment को तेज़ी से bootstrap करने का शानदार तरीका रहा है
  यूज़र बहुत ज़्यादा नहीं हैं, लेकिन https://formulae.brew.sh/analytics/os-version/365d/ के अनुसार Universal Blue के Bazzite (1.28%), Bluefin (0.49%), Aurora (0.28%) जैसे operating system डिफ़ॉल्ट रूप से Homebrew को bundled करके देते हैं
  संबंधित repository: https://github.com/ublue-os/brew

  • user-space package manager का विचार ऐसा लगता है जैसे Linux को यह समस्या 20 साल पहले ही सुलझा लेनी चाहिए थी
    non-root यूज़र के लिए आम स्थिति यह होना कि “XY इंस्टॉल नहीं कर सकते, लेकिन source से build करना चाहें तो कर लें” अपने आप में हास्यास्पद है
    Homebrew, Mise, Nix अभी उस खाली जगह को भर रहे हैं। Flatpak ज़्यादा GUI apps के करीब है, और Snap… खैर, मौजूद तो है
  • मैं Bazzite पर home-manager के साथ Nix इस्तेमाल कर रहा हूँ

• सबसे पहले जो तीन चीज़ें इंस्टॉल करता हूँ वे हैं Sublime Text, Homebrew, और latest Bash। Zsh पर स्विच करने का कोई इरादा नहीं है
  अच्छे टूल कंप्यूटिंग को आनंददायक बना देते हैं

  • पहले Homebrew इंस्टॉल करें, फिर उसी से Sublime और Bash इंस्टॉल कर लें

• मैं हाल ही में Nix से Homebrew पर वापस आया हूँ, और इसके तीन बड़े कारण हैं
  लगता है कि जिन पैकेजों का यह समर्थन करता है, उनके मामले में Brew, Nix से बेहतर है। Nix में कुछ पैकेज शायद अच्छी तरह मेंटेन नहीं किए जाते
  Mac support भी बेहतर है। कुछ Nix पैकेजों में macOS पर functionality बंद होती है, शायद इसलिए क्योंकि उस पैकेज के मेंटेनर के पास testing के लिए Mac नहीं है
  user experience भी बेहतर है
  बेशक, Nix environment की reproducibility और खास पैकेजों के साथ flake आसानी से बनाने की क्षमता की कमी महसूस होती है, लेकिन कुल मिलाकर Brew मुझे वापस ले आया। फिर भी मुझे Nix अब भी पसंद है, और कंपनी में भी Nix इस्तेमाल करते हैं

  • मैं nix-darwin इस्तेमाल करता हूँ और Homebrew पैकेज भी वहीं से manage करता हूँ। एक बार देखना चाहिए
    कंपनी में Nix का इस्तेमाल कहाँ करते हैं, यह जानने की जिज्ञासा है। कुछ जगहें ऐसी लगती हैं जहाँ Nix सही बैठता है, लेकिन उसे ठीक-ठीक पहचानना मुश्किल है
  • मुझे Nix में दिलचस्पी इसलिए थी कि शायद इससे macOS feature settings और configuration को automate किया जा सके
    लेकिन आम तौर पर बस defaults या किसी बीच के tool को चलाने तक बात सीमित रही
    आखिरकार मैंने Brew को ही रखा, और bash_profile में एक idempotent setupmac() function लिख लिया। मैं Bash 5 इस्तेमाल करता हूँ, और ChatGPT को अच्छे defaults commands पता थे, इसलिए उससे मदद ली
    dotfiles में रखे Brewfile के साथ इसने नए account या Mac setup की लगभग सारी दिक्कतें हल कर दीं, इसलिए ऐसे भारी-भरकम tools की ज़रूरत नहीं पड़ी

• Homebrew कोई कर्मचारियों वाला प्रोजेक्ट नहीं, बल्कि पूरी तरह volunteers द्वारा चलाया जाने वाला non-profit project है
  continuous integration, आगे के सुधारों के लिए ज़रूरी software, hardware, और hosting costs उठाने के लिए फंड चाहिए
  उनका कहना है कि हर donation बेहतर Homebrew बनाने में ही खर्च होता है, इसलिए GitHub Sponsors, OpenCollective, और Patreon के ज़रिए recurring support पर विचार किया जा सकता है
  मैंने उन open source projects को काफी donate किया है जिनसे मुझे फायदा मिला, लेकिन Homebrew के बारे में कभी गंभीरता से नहीं सोचा था, इसलिए अब support करना चाहिए

  • यह हैरानी की बात है कि Apple, या कम से कम Mac-केंद्रित बड़ी development companies, Homebrew को sponsor नहीं करतीं

• सोच रहा हूँ कि क्या Homebrew में किसी तरह का cooldown mechanism जोड़ा नहीं जा सकता
  अपने मशीन पर नया code जल्दी deploy करने के लिए मैं सिर्फ Apple और browsers पर भरोसा करना चाहता हूँ। browsers ऐसा इसलिए, क्योंकि वे किसी भी चीज़ से ज़्यादा untrusted input प्रोसेस करते हैं
  इसके अलावा vscode और extensions, npm, homebrew, और auto-updating apps के लिए मैं कुछ दिन इंतज़ार करना पसंद करता हूँ
  कुछ अपवादस्वरूप 0-day मामलों में cooldown bypass ज़रूरी हो सकता है, लेकिन अभी भी user brew upgrade चलाने तक 0-day के प्रति vulnerable ही रहता है

  • https://docs.brew.sh/Supply-Chain-Security में बताया गया है कि cooldown को कैसे handle किया जाता है और NPM जैसी चीज़ों की तुलना में risk profile इतना अलग क्यों है
    साथ ही NPM/PyPI/RubyGems से लाकर package की जाने वाली चीज़ों में, जो ऐसे attack का target बन सकती हैं, उनके लिए packaging के समय और नई version update PR बनाते समय पहले से cooldown लागू किया जाता है
  • यहाँ बात --minimum-release-age या minimumReleaseAge जैसे features की हो रही है, ताकि supply chain attack की vulnerability कम की जा सके
    ऐसे हमले अक्सर compromise होने के कुछ दिनों के भीतर पकड़ लिए जाते हैं
    Bun का उदाहरण: https://bun.com/docs/pm/cli/install#minimum-release-age
  • ज़्यादातर मामलों में यह release channels से संभाला जाता है। उदाहरण के लिए brew set-channel stable/edge जैसा कुछ
    इस हफ्ते Elixir 1.20 की घोषणा के बाद मेरे पास उसे कुछ मिनटों के लिए आज़माने का ही समय था, और Brew पीछे रह गया था, जिससे झुंझलाहट हुई
    erl और elixir को दूसरे तरीकों से भी install किया जा सकता है, और निजी तौर पर मैं उनका अपना toolchain पसंद करता हूँ, लेकिन उस समय इतना करना ठीक नहीं लगा
    Brew में कुछ recipes के लिए source options हैं या हुआ करते थे, और आँखें थोड़ा मींचकर देखें तो वह भी मूल रूप से एक समाधान ही है
  • सब कुछ rolling release है, लेकिन Homebrew में version को software author नहीं बल्कि Homebrew maintainer बढ़ाता है
    अपवाद तब हैं जब author खुद Homebrew core में PR डालता है या अपना Tap प्रकाशित करता है। Arch इसमें कैसे करता है, यह जानना रोचक होगा
  • यह इस release में शामिल है। “Cooldowns, livecheck and bumping” सेक्शन देखें

• Homebrew को संभव बनाने वाले सभी लोगों के लिए तालियाँ। प्रोजेक्ट को support करने पर विचार किया जा सकता है: https://opencollective.com/homebrew

• Intel support समाप्त करना कुछ आक्रामक-सा लगता है
  Mac को server की तरह इस्तेमाल करने वाले उत्साही लोग लगभग हमेशा पुराने machines इस्तेमाल करते हैं, और उनमें ज़्यादातर Intel हैं। उन्हें Apple से भी 1 साल पहले support खोना पड़ेगा
  मैं समझता हूँ कि Intel support बनाए रखना कठिन काम है और यह चुनाव का मामला है, लेकिन मेरा मानना है कि Homebrew को Intel support जितना संभव हो उतने लंबे समय तक बनाए रखने का रास्ता खोजना चाहिए

  • इसके उलट, लगता है कि Apple उत्साहियों की भारी बहुमत पूरी तरह Apple Silicon पर जा चुकी है
    पुराने Mac को server की तरह इस्तेमाल करने वाले लोग शायद rounding error के स्तर से भी आगे नहीं जाते होंगे
  • अगर Apple अपने कुछ resources भी Homebrew जैसी चीज़ों को maintain करने या वह काम करने वाले लोगों को pay करने में लगाता, तो शायद स्थिति अलग होती
  • इस समय तक वह Intel Mac शायद 2018 का Mac mini होगा, जो सिर्फ Sequoia तक चला सकता है, और Homebrew के Intel support खत्म करने के समय उसी के साथ support से बाहर हो जाएगा
    अगर Intel support चाहिए, तो MacPorts अब भी Leopard तक चलता है
  • --no-quarantine flag का support भी हटा दिया गया है
    इन दिनों मैं सिर्फ कुछ cask के लिए Homebrew इस्तेमाल करता हूँ और जहाँ तक हो सके उससे बचने की कोशिश करता हूँ। CLI tools के लिए Nix, Home-Manager, और Nix-Darwin इस्तेमाल करता हूँ
  • अच्छी बात यह है कि ऐसी machines Linux distros के लिए एकदम उपयुक्त हैं

• मैं बहुत ज़्यादा forced upgrades झेल चुका हूँ जिन्हें रोका नहीं जा सकता, इसलिए मैंने व्यक्तिगत रूप से Homebrew इस्तेमाल करना बंद कर दिया
  अब मैं Mise और MacPorts का कॉम्बिनेशन इस्तेमाल करता हूँ ताकि बिना चेतावनी के टूट-फूट और जबरन पुराना कर दिए जाने से बच सकूँ
  इसके अलावा, Mise में मनचाहे नए version पर जाया जा सकता है, लेकिन Homebrew में Tap कब upgrade करेगा इसका इंतज़ार करना पड़ता है। llama.cpp Tap तो हर 10 releases में एक बार skip भी कर देता है

  • यह जानकर सच में खुशी हुई कि आपको अपने लिए सही workflow मिल गया
    जो लोग अभी भी Homebrew इस्तेमाल करते हैं, उनके लिए केवल ज़रूरत पड़ने पर upgrade करने और upgrade से पहले उसे user को दिखाने के लिए बहुत काम किया गया है, और वह इस release में भी शामिल है
  • मैं भी पूछना चाह रहा था कि क्या किसी और का अनुभव भी ऐसा ही रहा है
    development tools install करने के लिए मैं कई सालों से MacPorts इस्तेमाल कर रहा हूँ, और यह कहीं ज़्यादा consistent है, साथ ही Python का नया major version यूँ ही अचानक आकर चौंकाता नहीं है
    Homebrew का इस्तेमाल मैं सिर्फ Firefox, Slack, Spotify जैसे applications install करने के लिए करता हूँ, जो MacPorts में नहीं हैं
    बेशक, मैं वर्षों से Python के लिए uv और nodejs के लिए pnpm पर जाने की कोशिश कर रहा हूँ, इसलिए अब यह मेरे लिए बहुत बड़ी समस्या न भी हो सकती है
  • Homebrew के आक्रामक support tier deprecation schedule की वजह से मैं MacPorts पर चला गया: https://docs.brew.sh/Support-Tiers
    मेरा रोज़ इस्तेमाल होने वाला iMac अब Tier-3 “दफ़ा हो जाओ” bucket में आ गया है
    जितने कम समय तक मैं इसे इस्तेमाल कर सका, उस दौरान मुझे Homebrew सच में बहुत पसंद था, लेकिन उसे चलते रहने के लिए hardware upgrade की treadmill पर चढ़ने का मेरा कोई इरादा नहीं है
  • मैं ज़्यादातर चीज़ें Mise पर ले जा चुका हूँ, अब बाकी के लिए MacPorts को देखना चाहिए
  • Nix को भी देखना चाहिए। Darwin packaging थोड़ी अस्थिर है, फिर भी जब आपको अक्सर Mac और Linux के बीच आना-जाना पड़ता है, तब cross-platform development shells होना सच में बहुत अच्छा है