Lançamento do Homebrew 6.0.0

• A API JSON interna, que reúne todos os metadados em um único download, passou a ser o padrão, acelerando as atualizações e reduzindo a comunicação de rede
  • A variável opt-in existente HOMEBREW_USE_INTERNAL_API foi marcada como deprecated
• Aplicação do sandbox Bubblewrap no Linux, isolando a execução das etapas de build, test e postinstall da mesma forma que no macOS
• Com base em pesquisas com usuários, o modo ask passou a ser o padrão para desenvolvedores, exibindo um resumo das dependências e um prompt de confirmação ao executar brew install e brew upgrade
• No brew bundle, a instalação paralela de formulae agora é executada automaticamente por padrão, com adição de extensões para npm e krew, além de suporte ao winget do Windows
• Melhorias de desempenho em toda a inicialização e no processo de upgrade, incluindo aceleração de cerca de 30% no brew leaves
• Adicionado suporte inicial ao macOS 27 (Golden Gate)
  • Com o fim do suporte a Intel, o macOS Intel x86_64 passará para Tier 3 em setembro de 2026, com descontinuação completa prevista para setembro de 2027
• Divulgação e correção de 3 avisos de segurança (bypass de redirecionamento HTTPS→HTTP, execução de código root em postinstall de .pkg, sequestro de propriedade de plist em /var/tmp)
• Adicionados novos comandos como o brew exec, semelhante ao npx, e o brew vulns, para verificar vulnerabilidades em pacotes instalados
• Introdução do framework de install steps, que expõe comportamentos comuns de postinstall e flight na API JSON como dados literais de DSL, eliminando a necessidade de baixar e avaliar arquivos Ruby em tarefas simples
• Aplicação de cooldown de download em ecossistemas de maior risco, como npm e PyPI, para mitigar riscos de segurança no fornecimento upstream

[lamanus]

Como faltam recursos para dar suporte até mesmo aos Macs com Intel, e como o GitHub Actions também não vai mais fornecer imagens, o Homebrew não tem outra opção além de seguir nessa direção.

[GN⁺]

Comentários do Hacker News

• Sou @bfontaine no GitHub. Ajudei na manutenção do Homebrew por volta de 2014~2016, e sempre me surpreende ver o Mike mantendo isso há mais de 16 anos e ainda lançando recursos novos

  • Em setembro fará 17 anos. Obrigado pela ótima contribuição naquela época, e espero que esteja bem
  • Homebrew é tão bom que eu uso até no Linux quando posso
    A maioria dos gerenciadores de pacotes do Linux não consegue separar os pacotes instalados pelo usuário dos pacotes do sistema, então é quase impossível organizar uma workstation e difícil decidir o que pode ser removido
    Além disso, os gerenciadores de pacotes nativos atualizam mais devagar que o Homebrew, então muitas vezes você acaba recebendo só pacotes desatualizados

• Como experimento, migrei todo o meu ambiente de desenvolvimento em nível de SO de Homebrew+pipx+npm para https://mise.jdx.dev/, e na prática funcionou muito bem
  Muitas ferramentas são instaladas diretamente de releases do GitHub ou do gerenciador de pacotes correspondente (uv, pnpm, go get etc.), então não existe código-cola de reempacotamento nem atraso de versão
  Dá para instalar versões arbitrárias ou várias versões ao mesmo tempo, e trocar dinamicamente a versão ativa por pasta de trabalho ou por ambiente
  Curiosamente, o Mise não oferece suporte a dependências, mas no geral isso não foi um problema. Ou o pnpm/uv resolve, ou são binários estáticos que simplesmente funcionam
  No passado, ao empacotar um app Python para o Homebrew, tive que trazer 50 dependências como resources, compilar tudo do código-fonte ou verificar manualmente se já existiam no Homebrew, declarar toolchains de build de 5 linguagens como dependências, esperar mais de 1 hora de CI a cada atualização, e aí um update do upstream criou um “loop de dependência em tempo de build” que não dava para resolver no Homebrew
  Então entendo perfeitamente por que o Mise escolhe o “caminho fácil” e depende diretamente dos gerenciadores de pacotes de cada linguagem
  A única coisa que não consegui substituir no Brewfile foi a Docker CLI necessária para se comunicar com o Colima, e para cask ainda uso Homebrew. Recomendo experimentar com o ambiente de desenvolvimento. Há muitas ferramentas novas excelentes hoje em dia

  • O Mise realmente parece estar em outra categoria. Como já disse em outros lugares, ele depende de registros como aqua ou asdf
    Para quem quer usar o Mise para pacotes do Homebrew, existe https://github.com/kennyg/mise-zerobrew
  • Como desenvolvedor PHP, o suporte do Mise ficou bem aquém do empacotamento de PHP que o Shivam Mathur vem fazendo para o Homebrew
    De qualquer forma, a maioria dos projetos usa Docker, e o PHP local serve para coisas que não precisam de Docker, como análise estática
    Também tenho alguns projetos que usam Nix, e o Nix humilha quase todo o resto, mas a experiência de uso como um todo é ainda mais hostil que a do git
  • Fico feliz que você teve uma boa experiência, mas pessoalmente acabei voltando do Mise para o Brew
    Pode ter sido falta de habilidade minha, mas havia pacotes demais dando problema no Mise
  • Gosto bastante do Mise, mas uso só para gerenciamento de ferramentas por projeto ou para coisas como versão do JDK
    Também tentei usá-lo para ferramentas globais do sistema, mas não combinou tão bem com ferramentas como Helix, NeoVim e RipGrep, em que basta estar mais ou menos atualizado e não me importo com a versão exata
  • O Mise até suporta dependências até certo ponto, mas não da forma que você esperaria em outros gerenciadores de pacotes
    As dependências no Mise não são automáticas; tudo precisa ser definido manualmente. Isso serve para evitar problemas de ordem causados por instalações paralelas. Por exemplo, se você usa pipx:black, precisa esperar a instalação do Python terminar. É para isso que serve a opção depends da ferramenta
    Isso é intencional no design. O Mise não foi projetado como uma solução completa de bootstrap, como Homebrew ou Nix, mas como uma sobreposição sobre um sistema já existente
    Então você pode gerenciar o Python com Brew e o black com Mise, e isso funciona praticamente sem configuração extra. Acho que essa decisão de design foi um grande acerto. Parece uma desvantagem, mas no fim talvez seja o principal motivo de os usuários acharem o Mise fácil de usar

• O Homebrew foi uma ótima forma de fazer bootstrap rápido de ambientes em distribuições Linux imutáveis
  Não são muitos usuários, mas segundo https://formulae.brew.sh/analytics/os-version/365d/, sistemas operacionais como Bazzite (1.28%), Bluefin (0.49%) e Aurora (0.28%) da Universal Blue já incluem o Homebrew por padrão
  O repositório relacionado é https://github.com/ublue-os/brew

  • O conceito de gerenciador de pacotes no espaço do usuário parece algo que o Linux já deveria ter resolvido há 20 anos
    É ridículo que a situação comum para um usuário sem root seja “não pode instalar XY, mas fique à vontade para compilar do código-fonte”
    Homebrew, Mise e Nix estão preenchendo esse vazio agora. Flatpak é mais voltado para apps GUI, e Snap... bem, existe
  • Estou usando Nix com home-manager no Bazzite

• As três primeiras coisas que instalo são Sublime Text, Homebrew e o Bash mais recente. Não pretendo mudar para o Zsh
  Boas ferramentas tornam a computação prazerosa

  • Você pode instalar o Homebrew primeiro e depois usar ele para instalar o Sublime e o Bash

• Voltei recentemente do Nix para o Homebrew de novo, e há três grandes motivos para isso
  O Brew parece ter suporte melhor para os pacotes que oferece do que o Nix. Alguns pacotes do Nix parecem não ser tão bem mantidos
  O suporte a Mac também é melhor. Alguns pacotes do Nix têm funcionalidades desativadas no macOS, e isso parece acontecer porque o mantenedor daquele pacote não tem um Mac para testar
  A experiência de uso também é melhor
  Claro que sinto falta da reprodutibilidade do ambiente no Nix e da capacidade de criar facilmente um flake com determinados pacotes, mas, no geral, o Brew me trouxe de volta. Ainda assim, continuo gostando do Nix e também usamos Nix na empresa

  • Uso nix-darwin e também gerencio por lá os pacotes do Homebrew. Vale a pena dar uma olhada
    Fico curioso para saber em que vocês usam Nix na empresa. Existem alguns lugares em que ele parece fazer sentido, mas é difícil apontar exatamente quais
  • Eu tinha interesse no Nix porque parecia que daria para automatizar a configuração e os ajustes de recursos do macOS
    Mas, no fim das contas, normalmente era só uma questão de rodar defaults ou alguma ferramenta intermediária
    Acabei mantendo o Brew e escrevendo uma função idempotente setupmac() no bash_profile. Uso Bash 5, e o ChatGPT ajudou bastante porque conhece bem os comandos de defaults
    Junto com o Brewfile que mantenho nos dotfiles, isso resolveu quase todos os problemas de configurar uma conta nova ou um Mac novo, então não preciso dessas ferramentas tão grandiosas

• O Homebrew é um projeto sem fins lucrativos operado inteiramente por voluntários, não por funcionários
  É preciso dinheiro para pagar integração contínua, software, hardware e hospedagem necessários para melhorias futuras
  Como todo o dinheiro das doações vai para tornar o Homebrew melhor para os usuários, talvez valha considerar apoio recorrente via GitHub Sponsors, OpenCollective ou Patreon
  Já doei bastante para projetos de código aberto dos quais me beneficio, mas nunca tinha pensado muito no Homebrew; agora acho que devo apoiar também

  • É surpreendente que a Apple, ou ao menos as grandes empresas de desenvolvimento focadas em Mac, não patrocinem o Homebrew

• Fico me perguntando se não daria para colocar algum tipo de mecanismo de cooldown no Homebrew
  Os únicos em que quero confiar para distribuir código novo rapidamente na minha máquina são a Apple e o navegador, porque o navegador processa muito mais entrada não confiável do que qualquer outra coisa
  Fora isso, para vscode e extensões, npm, homebrew e apps com atualização automática, prefiro esperar alguns dias
  Algumas exceções de 0-day podem exigir ignorar o cooldown, mas mesmo hoje o usuário continua vulnerável a 0-days até executar brew upgrade

  • Em https://docs.brew.sh/Supply-Chain-Security está explicado como eles tratam cooldowns e por que o perfil de risco é bem diferente de algo como NPM
    Além disso, para itens empacotados a partir de NPM/PyPI/RubyGems, que são alvos desse tipo de ataque, eles já aplicam cooldown tanto no empacotamento quanto na criação do PR de atualização para uma nova versão
  • O que estou querendo dizer aqui é um recurso como --minimum-release-age ou minimumReleaseAge, para reduzir a vulnerabilidade a ataques de cadeia de suprimentos
    Muitas vezes esses ataques são detectados poucos dias após a invasão
    Um exemplo no Bun: https://bun.com/docs/pm/cli/install#minimum-release-age
  • Na maioria dos casos isso é resolvido com canais de lançamento. Algo como brew set-channel stable/edge, por exemplo
    Esta semana, depois do anúncio do Elixir 1.20, eu só tinha alguns minutos para testar, e fiquei irritado porque o Brew ainda estava atrasado
    Dá para instalar erl e elixir de outras formas, e pessoalmente prefiro a própria toolchain deles, mas naquele momento não valia o esforço
    O Brew tem ou tinha opções de compilação a partir do código-fonte para algumas receitas e, apertando um pouco os olhos, isso também acaba sendo uma solução
  • É tudo rolling release, mas no Homebrew quem precisa subir a versão é o mantenedor do Homebrew, não o autor do software
    A exceção é quando o autor envia um PR para o Homebrew core ou publica o próprio Tap. Fico curioso sobre como o Arch lida com isso
  • Isso está incluído nesta release. Veja a seção “Cooldowns, livecheck and bumping”

• Palmas para todas as pessoas que tornam o Homebrew possível. Vale considerar apoiar o projeto: https://opencollective.com/homebrew

• O fim do suporte a Intel parece agressivo
  Quase todo entusiasta que usa Mac como servidor usa máquinas antigas, e a maioria delas é Intel. Vão perder suporte um ano antes da Apple
  Entendo que dar suporte a Intel é trabalhoso e uma questão de escolha, mas sou da opinião de que o Homebrew deveria encontrar uma forma de manter esse suporte pelo maior tempo possível

  • Na verdade, parece que a esmagadora maioria dos entusiastas da Apple já migrou totalmente para Apple Silicon
    Não acho que quem usa Macs antigos como servidor passe de uma margem de erro
  • Se a Apple tivesse usado ao menos parte dos seus recursos para manter algo como o Homebrew, ou para pagar as pessoas que fazem esse trabalho, talvez a situação fosse diferente
  • A esta altura, esse Mac Intel em questão provavelmente seria algo como um Mac mini de 2018, que só roda até o Sequoia e perderá suporte ao mesmo tempo em que o Homebrew deixar de oferecer suporte a Intel
    Se você precisa de suporte a Intel, o MacPorts ainda funciona até no Leopard
  • O suporte à flag --no-quarantine também foi removido
    Hoje em dia eu só uso o Homebrew para alguns casks e tento evitar o máximo possível. Para ferramentas de CLI uso Nix, Home-Manager e Nix-Darwin
  • Felizmente, essas máquinas são perfeitas para uma distribuição Linux

• Sofri demais com upgrades forçados que não dá para fixar versão, então pessoalmente parei de usar o Homebrew.
  Agora uso uma combinação de Mise e MacPorts para evitar quebras sem aviso e obsolescência forçada.
  Além disso, no Mise posso atualizar para qualquer versão nova quando quiser, mas no Homebrew você tem que esperar o Tap decidir quando vai atualizar. O Tap de llama.cpp chega a pular uma atualização a cada 10 releases.

  • Fico sinceramente feliz que você tenha encontrado um fluxo de trabalho que funcione.
    Para quem ainda usa Homebrew, foi feito muito trabalho para que ele só atualize quando for realmente necessário e para mostrar isso ao usuário antes da atualização, e isso também está incluído nesta release.
  • Eu ia justamente perguntar se mais alguém teve uma experiência parecida.
    Já faz alguns anos que uso MacPorts para instalar ferramentas de desenvolvimento, e ele é bem mais consistente, sem aparecer do nada uma nova versão major do Python para te pegar de surpresa.
    Uso Homebrew só para instalar aplicativos que não existem no MacPorts, como Firefox, Slack e Spotify.
    Claro que, ao longo dos anos, também venho tentando migrar Python para uv e nodejs para pnpm, então talvez hoje isso já não seja um grande problema para mim.
  • Migrei para o MacPorts por causa do cronograma agressivo de fim de suporte por níveis do Homebrew: https://docs.brew.sh/Support-Tiers
    Meu iMac de uso diário agora caiu no balde Tier-3 de “vai catar coquinho”.
    Eu realmente gostei do Homebrew no curto período em que pude usá-lo, mas não pretendo entrar na esteira de atualizar hardware só para continuar usando.
  • Estou numa fase em que já migrei a maior parte para o Mise, então vou dar uma olhada no MacPorts para o que falta.
  • Vale a pena dar uma olhada no Nix também. Apesar de o empacotamento no Darwin ser meio instável, é muito bom ter shells de desenvolvimento multiplataforma quando você precisa alternar entre Mac e Linux com frequência.