Lanzamiento de Homebrew 6.0.0

• La API JSON interna que agrupa todos los metadatos en una sola descarga pasa a ser el valor predeterminado, acelerando las actualizaciones y reduciendo la comunicación de red
  • La variable opt-in existente HOMEBREW_USE_INTERNAL_API queda marcada como deprecated
• Se aplica Bubblewrap sandbox en Linux, aislando la ejecución de las etapas de build, test y postinstall igual que en macOS
• Reflejando la encuesta a usuarios, el modo ask pasa a ser el predeterminado para desarrolladores, mostrando un resumen de dependencias y una confirmación al ejecutar brew install y brew upgrade
• En brew bundle, la instalación paralela de formulae se ejecuta automáticamente por defecto, y se agregan extensiones para npm y krew, además de soporte para winget en Windows
• Mejoras de rendimiento en todo el arranque y las actualizaciones, incluida una aceleración de alrededor de 30% en brew leaves
• Se agrega soporte inicial para macOS 27 (Golden Gate)
  • Debido al fin del soporte para Intel, en septiembre de 2026 macOS Intel x86_64 pasará a Tier 3, y en septiembre de 2027 dejará de ser compatible por completo
• Se publican y corrigen tres avisos de seguridad (bypass de redirección HTTPS→HTTP, ejecución de código root en postinstall de .pkg, y secuestro de propiedad de plist en /var/tmp)
• Se agregan nuevos comandos como brew exec, similar a npx, y brew vulns, para revisar vulnerabilidades en paquetes instalados
• Se introduce el install steps framework, que expone en la API JSON los comportamientos comunes de postinstall y flight como datos literales del DSL, evitando descargar y evaluar archivos Ruby en tareas simples
• Se aplica cooldown a las descargas en ecosistemas de mayor riesgo como npm y PyPI para mitigar riesgos de seguridad de suministro upstream

[lamanus]

No hay suficientes recursos para seguir dando soporte hasta a las Mac Intel, y como GitHub Actions tampoco planea seguir ofreciendo imágenes, Homebrew no tiene otra opción más que avanzar en esa misma dirección.

[GN⁺]

Comentarios de Hacker News

• Soy @bfontaine de GitHub. Ayudé con el mantenimiento de Homebrew por ahí de 2014~2016, y siempre me sorprende ver que Mike lo siga manteniendo después de más de 16 años y que todavía saque funciones nuevas

  • En septiembre se cumplen 17 años. Gracias por haber contribuido tan bien en ese entonces, y espero que te esté yendo bien
  • Homebrew me gusta tanto que lo uso en Linux también cuando puedo
    La mayoría de los gestores de paquetes de Linux no pueden separar los paquetes instalados por el usuario de los paquetes del sistema, así que es casi imposible ordenar una estación de trabajo y cuesta saber qué se puede borrar
    Además, los gestores de paquetes nativos actualizan más lento que Homebrew, así que muchas veces terminas recibiendo solo paquetes viejos

• Como experimento, moví todo mi entorno de desarrollo a nivel de OS de Homebrew+pipx+npm a https://mise.jdx.dev/, y en la práctica ha funcionado muy bien
  Muchas herramientas se instalan directo desde GitHub Releases o desde su gestor de paquetes correspondiente (uv, pnpm, go get, etc.), así que no hay código pegamento para reempaquetar ni retrasos de versión
  Puedes instalar cualquier versión o varias versiones al mismo tiempo, y cambiar dinámicamente la versión activa por carpeta de trabajo o por entorno
  Curiosamente, Mise no soporta dependencias, pero en general no fue problema. pnpm/uv se encargan de eso o son binarios estáticos y simplemente funcionan
  Antes empaqueté una app de Python para Homebrew trayendo 50 dependencias como resources, compilándolas todas desde código fuente o verificando manualmente si estaban en Homebrew, declarando como dependencias toolchains de compilación de 5 lenguajes, esperando más de 1 hora al CI en cada actualización, y luego una actualización de upstream creó un “bucle de dependencias en tiempo de compilación” que ya no se podía resolver en Homebrew
  Por eso entiendo perfectamente por qué Mise eligió el “camino fácil” y depende directamente de los gestores de paquetes de cada lenguaje
  Lo único que no pude reemplazar desde Brewfile fue el Docker CLI necesario para comunicarme con Colima, y para los casks sigo usando Homebrew. Recomiendo experimentar con el entorno de desarrollo. Hoy en día hay muchas herramientas nuevas excelentes

  • Mise definitivamente parece estar en otra liga. Como dije en otros lados, depende de registros como aqua o asdf
    Para quienes quieran usar Mise con paquetes de Homebrew, está https://github.com/kennyg/mise-zerobrew
  • Como desarrollador de PHP, el soporte de Mise se quedó bastante corto frente al empaquetado de PHP que Shivam Mathur ha hecho para Homebrew
    De todos modos, la mayoría de los proyectos usan Docker, y el PHP local es para cosas como análisis estático donde Docker no hace falta
    También tengo algunos proyectos que usan Nix, y Nix se burla de todo lo demás, pero la experiencia de usuario completa es aún más hostil que git
  • Me alegra que hayas tenido una buena experiencia, pero en lo personal volví de Mise a Brew
    Puede haber sido falta de habilidad de mi parte, pero hubo demasiados paquetes con los que tuve problemas en Mise
  • Me gusta mucho Mise, pero solo lo uso para gestionar herramientas por proyecto o para cosas como la versión de JDK
    También lo probé con herramientas globales del sistema, pero no me sirvió tanto para cosas como Helix, NeoVim o RipGrep, donde basta con tener algo más o menos reciente y no me importa una versión exacta
  • Mise sí soporta dependencias hasta cierto punto, pero no de la forma en que lo esperarías de otros gestores de paquetes
    Las dependencias en Mise no son automáticas y todas se tienen que definir manualmente. Sirven para evitar problemas de orden causados por la instalación en paralelo. Por ejemplo, si usas pipx:black, tiene que esperar a que termine la instalación de Python. Para eso está la opción depends de la herramienta
    Es un diseño intencional. Mise no fue diseñado como una solución completa de bootstrap como Homebrew o Nix, sino como una capa superpuesta sobre un sistema existente
    Así que puedes gestionar Python con Brew y black con Mise, y casi todo funciona tal cual sin configuración adicional. Creo que esta decisión de diseño fue un gran acierto. Puede sonar como una desventaja, pero al final probablemente sea la razón principal por la que a los usuarios Mise les resulta fácil

• Homebrew fue una gran forma de hacer bootstrap rápido del entorno en distribuciones Linux inmutables
  No hay tantos usuarios, pero según https://formulae.brew.sh/analytics/os-version/365d/, sistemas operativos como Bazzite (1.28%), Bluefin (0.49%) y Aurora (0.28%) de Universal Blue ya incluyen Homebrew por defecto
  El repositorio relacionado es https://github.com/ublue-os/brew

  • La idea de un gestor de paquetes en espacio de usuario parece algo que Linux debió haber resuelto hace 20 años
    Es ridículo que la situación normal para un usuario sin root sea “no puedes instalar XY, pero si quieres compilarlo desde código fuente, adelante”
    Homebrew, Mise y Nix están llenando ese vacío ahora. Flatpak está más del lado de las apps GUI, y Snap… bueno, existe
  • Estoy usando Nix con home-manager en Bazzite

• Las tres primeras cosas que instalo son Sublime Text, Homebrew y la última versión de Bash. No pienso cambiarme a Zsh
  Las buenas herramientas hacen que usar una computadora sea divertido

  • Primero puedes instalar Homebrew y luego usarlo para instalar Sublime y Bash

• Hace poco volví de Nix a Homebrew, y hay tres razones principales.
  Brew parece ofrecer mejor soporte para los paquetes que uso que Nix. Da la impresión de que algunos paquetes de Nix no están tan bien mantenidos.
  El soporte para Mac también es mejor. Algunos paquetes de Nix tienen funciones desactivadas en macOS, y parece que eso pasa porque quien los mantiene no tiene una Mac para probar.
  La experiencia de usuario también es mejor.
  Claro, extraño la reproducibilidad del entorno de Nix y la capacidad de crear fácilmente un flake con ciertos paquetes, pero en conjunto Brew me hizo volver. Aun así, Nix me sigue gustando y en la empresa también usamos Nix.

  • Uso nix-darwin y también gestiono ahí los paquetes de Homebrew. Vale la pena echarle un vistazo.
    Me da curiosidad en qué usan Nix en la empresa. Hay algunos lugares donde parece encajar bien, pero me cuesta identificar exactamente cuáles.
  • Me interesaba Nix porque parecía que podría automatizar la configuración y los ajustes de funciones de macOS.
    Pero por lo general solo terminaba ejecutando defaults o alguna herramienta intermedia.
    Al final mantuve Brew y escribí una función idempotente setupmac() en bash_profile. Uso Bash 5, y ChatGPT me ayudó porque conoce bien los comandos defaults.
    Junto con el Brewfile que mantengo en mis dotfiles, eso casi resolvió por completo los problemas de configurar una cuenta nueva o una nueva Mac, así que no necesito herramientas tan aparatosas.

• Homebrew es un proyecto sin fines de lucro operado totalmente por voluntarios, no por empleados.
  Se necesita financiamiento para cubrir integración continua, software, hardware y hosting para futuras mejoras.
  Dicen que todas las donaciones se usan para hacer mejor Homebrew para los usuarios, así que vale la pena considerar un aporte recurrente por GitHub Sponsors, OpenCollective o Patreon.
  He donado bastante a proyectos de código abierto de los que me beneficio, pero nunca había pensado mucho en Homebrew, así que ya es hora de apoyarlo.

  • Me sorprende que Apple, o al menos las principales empresas de desarrollo centradas en Mac, no patrocinen Homebrew.

• Me pregunto si no se podría añadir algún tipo de mecanismo de enfriamiento a Homebrew.
  Solo Apple y los navegadores me generan confianza para desplegar código nuevo rápidamente en mi máquina. Los navegadores porque procesan entradas no confiables más que casi cualquier otra cosa.
  Para todo lo demás —vscode y sus extensiones, npm, homebrew, apps con autoactualización— prefiero esperar unos días.
  Algunos 0-day excepcionales podrían requerir saltarse ese enfriamiento, pero incluso ahora el usuario sigue siendo vulnerable a un 0-day hasta que ejecuta brew upgrade.

  • En https://docs.brew.sh/Supply-Chain-Security se explica cómo manejan el enfriamiento y por qué el perfil de riesgo es muy distinto al de algo como NPM.
    Además, para los elementos que se traen y empaquetan desde NPM/PyPI/RubyGems y que sí serían objetivo de este tipo de ataque, ya aplican enfriamiento al momento de empaquetarlos y cuando crean PRs para actualizar a nuevas versiones.
  • A lo que me refiero aquí es a una función como --minimum-release-age o minimumReleaseAge para reducir la vulnerabilidad a ataques de cadena de suministro.
    Este tipo de ataques muchas veces se detecta en los días posteriores a una intrusión.
    Un ejemplo en Bun: https://bun.com/docs/pm/cli/install#minimum-release-age
  • La mayoría de las veces esto se maneja con canales de lanzamiento. Por ejemplo, algo como brew set-channel stable/edge.
    Esta semana, después del anuncio de Elixir 1.20, solo tuve unos minutos para probarlo y me molestó que Brew estuviera retrasado.
    erl y elixir se pueden instalar de otras maneras y en lo personal prefiero su propia toolchain, pero en ese momento no valía la pena.
    Brew tiene o tenía opciones de compilación desde código fuente en algunas recetas y, si uno entrecierra los ojos, eso también termina siendo una solución.
  • Todo es rolling release, pero en Homebrew quien tiene que subir la versión es quien mantiene Homebrew, no quien escribe el software.
    Las excepciones son cuando el autor abre un PR a Homebrew core o publica su propio Tap. Me da curiosidad cómo maneja esto Arch.
  • Ya viene en esta versión. Solo hay que ver la sección “Cooldowns, livecheck and bumping”.

• Aplausos para toda la gente que hace posible Homebrew. Vale la pena considerar apoyar el proyecto: https://opencollective.com/homebrew

• El fin del soporte para Intel se siente agresivo.
  Casi toda la gente entusiasta que usa Macs como servidores lo hace con máquinas viejas, y la mayoría son Intel. Van a perder soporte un año antes que con Apple.
  Entiendo que mantener el soporte para Intel es pesado y una cuestión de elección, pero me inclino por pensar que Homebrew debería encontrar una forma de mantenerlo el mayor tiempo posible.

  • Más bien, me parece que la abrumadora mayoría de entusiastas de Apple ya migró por completo a Apple Silicon.
    No creo que quienes usan Macs viejas como servidores lleguen siquiera a superar el margen de error.
  • Si Apple hubiera dedicado хотя бы una parte de sus recursos a mantener algo como Homebrew o a pagarle a la gente que hace ese trabajo, la situación podría haber sido distinta.
  • A estas alturas, esa Mac Intel probablemente sería una Mac mini de 2018, que solo puede correr hasta Sequoia y quedará sin soporte al mismo tiempo que Homebrew deje de dar soporte a Intel.
    Si necesitas soporte para Intel, MacPorts sigue funcionando incluso hasta Leopard.
  • También eliminaron el soporte para la bandera --no-quarantine.
    Hoy en día solo uso Homebrew para algunos casks y trato de evitarlo cuando puedo. Para herramientas CLI uso Nix, Home-Manager y Nix-Darwin.
  • Por suerte, esas máquinas siguen siendo perfectas para una distribución de Linux.

• Dejé de usar Homebrew personalmente después de aguantar demasiadas actualizaciones forzadas que no se pueden fijar
  Ahora uso una combinación de Mise y MacPorts para evitar roturas sin aviso y obsolescencia forzada
  Además, con Mise puedo subir a cualquier versión nueva, pero con Homebrew tengo que esperar a que el Tap decida cuándo actualizar. El Tap de llama.cpp incluso se salta una de cada 10 releases

  • De verdad me alegra que hayas encontrado un flujo de trabajo que te funciona
    Se ha trabajado mucho para que quienes todavía usan Homebrew solo actualicen cuando sea necesario y para mostrarlo al usuario antes de actualizar, y eso también viene incluido en esta release
  • Justo iba a preguntar si alguien más había tenido una experiencia parecida
    Llevo años usando MacPorts para instalar herramientas de desarrollo, y ha sido mucho más consistente, sin que de repente aparezca una nueva versión mayor de Python para sorprenderme
    Solo uso Homebrew para instalar aplicaciones que no están en MacPorts, como Firefox, Slack y Spotify
    Claro, también llevo años tratando de mover Python a uv y nodejs a pnpm, así que quizá ya no sea un gran problema para mí
  • Me cambié a MacPorts por el agresivo calendario de fin de soporte por etapas de Homebrew: https://docs.brew.sh/Support-Tiers
    Mi iMac de uso diario ahora cayó en el bucket Tier-3 de “vete al demonio”
    De verdad me encantó Homebrew durante el poco tiempo en que pude usarlo, pero no pienso subirme a la caminadora de actualizar hardware para poder seguir usándolo
  • Estoy en proceso de mover casi todo a Mise, pero para lo que falta tendré que echarle un vistazo a MacPorts
  • También vale la pena revisar Nix. El empaquetado en Darwin es algo inestable, pero cuando tienes que moverte seguido entre Mac y Linux, está muy bien tener shells de desarrollo multiplataforma