Sortie de Homebrew 6.0.0

• L’API JSON interne qui regroupe toutes les métadonnées en un seul téléchargement devient l’option par défaut, ce qui accélère les mises à jour et réduit les communications réseau
  • L’ancienne variable d’activation HOMEBREW_USE_INTERNAL_API est désormais dépréciée
• Application du sandbox Bubblewrap sur Linux, avec isolation des étapes de build, test et postinstall comme sur macOS
• Suite aux retours de l’enquête utilisateur, le mode ask devient la valeur par défaut pour les développeurs, avec affichage d’un résumé des dépendances et d’une invite de confirmation lors de brew install et brew upgrade
• Dans brew bundle, l’installation parallèle des formulae est désormais activée automatiquement par défaut, avec ajout des extensions npm, krew et du support de winget sur Windows
• Améliorations de performances sur l’ensemble du démarrage et des mises à niveau, dont environ 30 % d’accélération pour brew leaves
• Ajout d’un support initial pour macOS 27 (Golden Gate)
  • Avec la fin du support Intel, macOS Intel x86_64 passera en Tier 3 en septembre 2026, puis sera totalement non pris en charge à partir de septembre 2027
• Publication et correction de 3 avis de sécurité (contournement de redirection HTTPS→HTTP, exécution de code root en postinstall .pkg, prise de contrôle de propriété de plist dans /var/tmp)
• Ajout de nouvelles commandes comme brew exec, similaire à npx, et brew vulns pour vérifier les vulnérabilités des paquets installés
• Introduction de l’install steps framework, qui expose dans l’API JSON les comportements communs de postinstall et de flight sous forme de données DSL littérales, évitant de télécharger et d’évaluer des fichiers Ruby pour les tâches simples
• Application d’un cooldown des téléchargements pour les écosystèmes à risque comme npm et PyPI afin d’atténuer les risques de sécurité côté approvisionnement upstream

[lamanus]

Les ressources sont insuffisantes pour continuer à prendre en charge les Mac Intel, et comme GitHub Actions ne prévoit plus non plus de fournir d’images, Homebrew n’a pas d’autre choix que d’avancer dans ce sens.

[GN⁺]

Avis sur Hacker News

• C’est @bfontaine sur GitHub. J’ai aidé à la maintenance de Homebrew vers 2014~2016, et je suis toujours impressionné de voir Mike continuer à le maintenir depuis plus de 16 ans tout en sortant encore de nouvelles fonctionnalités

  • En septembre, ça fera 17 ans. Merci encore pour ton excellente contribution à l’époque, et j’espère que tu vas bien
  • J’aime tellement Homebrew que je l’utilise aussi sur Linux quand c’est possible
    La plupart des gestionnaires de paquets Linux ne savent pas séparer les paquets installés par l’utilisateur des paquets système, ce qui rend presque impossible de garder un poste de travail propre et de savoir ce qu’on peut supprimer
    En plus, les gestionnaires de paquets natifs sont souvent plus lents à mettre à jour que Homebrew, donc on se retrouve souvent avec des paquets obsolètes

• Par curiosité, j’ai migré tout mon environnement de développement au niveau OS de Homebrew+pipx+npm vers https://mise.jdx.dev/, et en pratique ça fonctionne très bien
  Beaucoup d’outils s’installent directement depuis les releases GitHub ou leur gestionnaire de paquets correspondant (uv, pnpm, go get, etc.), donc il n’y a pas de code de glue de repackaging ni de retard sur les versions
  On peut installer une version arbitraire ou plusieurs versions en parallèle, et changer dynamiquement la version active selon le dossier de travail ou l’environnement
  Fait intéressant, Mise ne gère pas vraiment les dépendances, mais dans la plupart des cas ça ne pose pas de problème. Soit pnpm/uv s’en charge, soit ce sont des binaires statiques qui fonctionnent tels quels
  J’avais déjà empaqueté une application Python pour Homebrew en récupérant 50 dépendances via resources, en compilant tout depuis les sources ou en vérifiant manuellement si elles existaient dans Homebrew, en déclarant comme dépendances des toolchains de build de 5 langages, puis en attendant plus d’une heure la CI à chaque mise à jour, avant qu’une mise à jour upstream ne crée une « boucle de dépendances au moment de la build » impossible à résoudre dans Homebrew
  Du coup, je comprends parfaitement pourquoi Mise a choisi la « voie facile » en s’appuyant directement sur les gestionnaires de paquets propres à chaque langage
  La seule chose que je n’ai pas pu remplacer dans mon Brewfile, c’est la CLI Docker nécessaire pour communiquer avec Colima, et pour les casks j’utilise toujours Homebrew. Je recommande d’expérimenter son environnement de développement. Il y a beaucoup d’excellents nouveaux outils en ce moment

  • Mise semble clairement dans une catégorie à part. Comme je l’ai déjà dit ailleurs, il dépend de registres comme aqua ou asdf
    Pour ceux qui veulent utiliser Mise sur des paquets Homebrew, il y a https://github.com/kennyg/mise-zerobrew
  • En tant que développeur PHP, j’ai trouvé que la prise en charge de Mise était assez en retrait par rapport à ce que Shivam Mathur faisait pour l’empaquetage PHP dans Homebrew
    La plupart des projets utilisent de toute façon Docker, et le PHP local sert à des usages qui n’en ont pas besoin, comme l’analyse statique
    J’ai aussi quelques projets qui utilisent Nix, et Nix écrase à peu près tout le reste, mais l’expérience utilisateur globale est encore plus hostile que git
  • Content que ça se soit bien passé pour toi, mais personnellement je suis finalement revenu de Mise à Brew
    C’était peut-être un problème de mon côté, mais j’ai eu trop de paquets qui posaient problème dans Mise
  • J’aime beaucoup Mise, mais je ne l’utilise que pour la gestion d’outils par projet ou pour des choses comme les versions de JDK
    Je l’ai aussi essayé pour des outils globaux au système, mais ce n’était pas très adapté à des outils comme Helix, NeoVim ou RipGrep, où il suffit grosso modo d’avoir une version récente sans se soucier d’une version précise
  • Mise gère quand même les dépendances dans une certaine mesure, mais pas de la manière attendue dans d’autres gestionnaires de paquets
    Les dépendances dans Mise ne sont pas automatiques, il faut toutes les définir à la main. C’est fait pour éviter les problèmes d’ordre liés aux installations en parallèle. Par exemple, avec pipx:black, il faut attendre que l’installation de Python soit terminée. C’est le rôle de l’option depends de l’outil
    C’est intentionnel. Mise n’a pas été conçu comme une solution de bootstrap complète à la Homebrew ou Nix, mais comme un overlay posé sur un système existant
    Donc on peut gérer Python avec Brew et black avec Mise, et ça fonctionne presque tel quel sans configuration particulière. Je pense que ce choix de conception est une vraie réussite. Ça peut sembler être un inconvénient, mais c’est probablement l’une des principales raisons pour lesquelles les utilisateurs trouvent Mise facile à prendre en main

• Homebrew a été un excellent moyen de bootstrapper rapidement un environnement sur des distributions Linux immuables
  Il n’y a pas énormément d’utilisateurs, mais d’après https://formulae.brew.sh/analytics/os-version/365d/, des systèmes d’exploitation comme Bazzite (1,28 %), Bluefin (0,49 %) et Aurora (0,28 %) de Universal Blue embarquent Homebrew par défaut
  Le dépôt associé est https://github.com/ublue-os/brew

  • Le concept de gestionnaire de paquets en espace utilisateur donne l’impression d’être quelque chose que Linux aurait dû résoudre il y a déjà 20 ans
    Le fait que, dans la situation classique d’un utilisateur non root, on en soit encore à « on ne peut pas installer XY, mais on peut compiler depuis les sources » est absurde
    Homebrew, Mise et Nix comblent aujourd’hui ce vide. Flatpak est plus orienté applis GUI, et Snap… existe
  • J’utilise Nix avec home-manager sur Bazzite

• Les trois premières choses que j’installe sont Sublime Text, Homebrew et la dernière version de Bash. Je n’ai aucune intention de passer à Zsh
  Les bons outils rendent l’informatique agréable

  • Il suffit d’installer Homebrew d’abord, puis de s’en servir pour installer Sublime et Bash

• Je suis récemment revenu de Nix à Homebrew, pour trois grandes raisons
  Brew semble mieux prendre en charge les paquets que j’utilise que Nix. Certains paquets Nix donnent l’impression d’être mal maintenus
  Le support Mac est aussi meilleur. Certains paquets Nix ont des fonctionnalités désactivées sur macOS, probablement parce que leur mainteneur n’a pas de Mac pour les tester
  L’expérience utilisateur est meilleure aussi
  Bien sûr, la reproductibilité des environnements Nix et la facilité à créer un flake contenant des paquets précis me manquent, mais dans l’ensemble Brew m’a fait revenir. Cela dit, j’aime toujours Nix et on l’utilise aussi dans mon entreprise

  • J’utilise nix-darwin et je gère aussi les paquets Homebrew depuis là. Ça vaut le coup d’y jeter un œil
    Je me demande où vous utilisez Nix dans votre entreprise. Il y a quelques endroits où ça semble adapté, mais c’est difficile à cerner précisément
  • Nix m’intéressait parce que je pensais pouvoir automatiser les réglages et la configuration des fonctionnalités de macOS
    Mais en pratique, cela revenait surtout à exécuter defaults ou un outil intermédiaire
    J’ai donc fini par garder Brew et par écrire une fonction idempotente setupmac() dans mon bash_profile. J’utilise Bash 5, et ChatGPT m’a bien aidé en connaissant de chouettes commandes defaults
    Avec le Brewfile que je garde dans mes dotfiles, j’ai pratiquement résolu tous les problèmes de configuration d’un nouveau compte ou d’un nouveau Mac, donc je n’ai pas besoin d’outils aussi ambitieux

• Homebrew est un projet à but non lucratif géré entièrement par des bénévoles, pas par des salariés
  Il faut des fonds pour payer l’intégration continue, les logiciels, le matériel et l’hébergement nécessaires aux améliorations futures
  Puisque tous les dons servent à améliorer Homebrew pour les utilisateurs, cela vaut la peine d’envisager un soutien régulier via GitHub Sponsors, OpenCollective ou Patreon
  J’ai beaucoup donné à des projets open source dont je bénéficie, mais je n’avais jamais vraiment réfléchi à Homebrew, donc je vais le soutenir maintenant

  • Je suis surpris qu’Apple, ou au moins les grandes entreprises de développement centrées sur le Mac, ne sponsorisent pas Homebrew

• Je me demande s’il ne serait pas possible d’ajouter une sorte de mécanisme de cooldown à Homebrew
  Les seules entités auxquelles j’ai envie de faire confiance pour déployer rapidement du nouveau code sur ma machine sont Apple et les navigateurs. Les navigateurs traitent plus d’entrées non fiables que n’importe quoi d’autre
  Pour tout le reste — vscode et ses extensions, npm, homebrew, les applications à mise à jour automatique — je préfère attendre quelques jours
  Quelques 0-day exceptionnels peuvent nécessiter de contourner ce cooldown, mais même aujourd’hui l’utilisateur reste vulnérable à un 0-day tant qu’il n’exécute pas brew upgrade

  • La page https://docs.brew.sh/Supply-Chain-Security explique comment les cooldowns sont gérés et pourquoi le profil de risque est très différent de celui de NPM et autres
    De plus, pour les éléments empaquetés à partir de NPM/PyPI/RubyGems qui sont visés par ce type d’attaque, un cooldown est déjà appliqué au moment du packaging et lors de la création des PR de mise à jour vers une nouvelle version
  • Ce dont il est question ici, c’est d’une fonctionnalité comme --minimum-release-age ou minimumReleaseAge pour réduire la vulnérabilité aux attaques de la chaîne d’approvisionnement
    Ce genre d’attaques est souvent détecté dans les quelques jours qui suivent une compromission
    Exemple côté Bun : https://bun.com/docs/pm/cli/install#minimum-release-age
  • En général, cela se gère avec des canaux de publication. Par exemple brew set-channel stable/edge
    Cette semaine, juste après l’annonce d’Elixir 1.20, je n’avais que quelques minutes pour l’essayer et j’étais agacé que Brew soit à la traîne
    erl et elixir peuvent aussi s’installer autrement, et personnellement je préfère leur toolchain native, mais à ce moment-là cela ne valait pas l’effort
    Brew a ou avait des options de compilation depuis les sources pour certaines recettes, et en plissant un peu les yeux, on peut voir ça comme une solution de base aussi
  • Tout est en rolling release, mais dans Homebrew, c’est au mainteneur Homebrew de monter les versions, pas à l’auteur du logiciel
    Il y a des exceptions quand l’auteur ouvre une PR sur Homebrew core ou publie son propre tap. Je me demande comment Arch gère cela
  • C’est inclus dans cette version. Voir la section “Cooldowns, livecheck and bumping”

• Bravo à toutes les personnes qui rendent Homebrew possible. Cela vaut le coup d’envisager de soutenir le projet : https://opencollective.com/homebrew

• La fin du support Intel semble agressive
  Presque tous les passionnés qui utilisent des Mac comme serveurs emploient de vieilles machines, et la plupart sont des Intel. Ils perdront le support un an avant Apple
  Je comprends que le support Intel soit pénible et relève d’un choix, mais je pense que Homebrew devrait chercher un moyen de le maintenir aussi longtemps que possible

  • Au contraire, l’écrasante majorité des passionnés Apple semble être passée complètement à Apple Silicon
    À mon avis, les gens qui utilisent d’anciens Mac comme serveurs ne dépassent pas le niveau d’une erreur d’arrondi
  • Si Apple consacrait ne serait-ce qu’une partie de ses ressources à maintenir quelque chose comme Homebrew ou à rémunérer les personnes qui font ce travail, la situation aurait peut-être été différente
  • À ce stade, le Mac Intel concerné serait probablement un Mac mini 2018, qui ne peut aller que jusqu’à Sequoia et perdra le support en même temps que Homebrew abandonnera Intel
    Si vous avez besoin du support Intel, MacPorts fonctionne encore jusqu’à Leopard
  • La prise en charge du drapeau --no-quarantine a aussi été supprimée
    De nos jours, je n’utilise Homebrew que pour quelques casks et j’essaie de l’éviter autant que possible. Pour les outils CLI, j’utilise Nix, Home-Manager et Nix-Darwin
  • Heureusement, ces machines sont parfaites pour une distribution Linux

• J’ai personnellement arrêté d’utiliser Homebrew après avoir subi trop de mises à niveau forcées impossibles à bloquer
  J’utilise maintenant une combinaison de Mise et MacPorts pour éviter les casses imprévues et l’obsolescence forcée
  En plus, Mise permet de passer à n’importe quelle nouvelle version, alors qu’avec Homebrew il faut attendre que le Tap décide quand effectuer la mise à niveau. Le Tap llama.cpp saute parfois dix releases d’un coup

  • Je suis sincèrement content que tu aies trouvé un workflow qui te convienne
    Beaucoup de travail a été fait pour que les mises à niveau n’aient lieu que lorsqu’elles sont vraiment nécessaires et pour les afficher à l’utilisateur avant qu’elles ne se produisent, et cela fait aussi partie de cette release
  • J’allais justement demander si d’autres avaient eu une expérience similaire
    J’utilise MacPorts depuis des années pour installer les outils de développement, et c’est bien plus cohérent, sans nouvelle version majeure de Python qui surgit aléatoirement pour te surprendre
    Je n’utilise Homebrew que pour installer des applications comme Firefox, Slack et Spotify, qui ne sont pas disponibles dans MacPorts
    Bien sûr, cela fait des années que j’essaie de migrer Python vers uv et nodejs vers pnpm, donc ce n’est peut-être plus vraiment un gros problème pour moi maintenant
  • Je suis passé à MacPorts à cause du calendrier agressif de fin de prise en charge par paliers de Homebrew : https://docs.brew.sh/Support-Tiers
    Mon iMac de tous les jours se retrouve désormais dans le bucket Tier-3 « va te faire voir »
    J’ai vraiment adoré Homebrew pendant la courte période où j’ai pu l’utiliser, mais je n’ai aucune intention de monter sur le tapis roulant des mises à niveau matérielles juste pour continuer à m’en servir
  • J’en suis à l’étape où j’ai migré la plupart des choses vers Mise, mais je devrais regarder MacPorts pour ce qu’il reste
  • Nix vaut aussi le coup d’œil. Le packaging Darwin est parfois un peu instable, mais avoir des shells de développement multiplateformes est vraiment appréciable quand on doit souvent passer de Mac à Linux