Comment utiliser Homebrew sur un Mac Apple Silicon
Si vous avez la chance d’utiliser un Mac Apple Silicon et que vous avez besoin d’utiliser le gestionnaire de paquets Homebrew, vous avez probablement été fort déçu en voyant que la ligne de commande habituelle pour l’installer affiche un message d’erreur :
Homebrew n’est pas encore une app optimisée Apple Silicon et elle doit fonctionner avec Rosetta. Le problème supplémentaire qui se pose dans ce cas est que c’est un outil en ligne de commandes à utiliser dans le terminal. L’app Terminal de macOS étant optimisée pour la nouvelle architecture d’Apple1, elle considère par défaut que c’est le cas pour toutes les commandes que vous y saisissez. Comme ce n’est pas le cas pour Homebrew, il y a un problème.
Pour le régler, les développeurs du gestionnaire de paquets suggèrent deux solutions :
- Bloquer l’app Terminal sur Rosetta ;
- Forcer l’installation de Homebrew sur Rosetta.
La première solution consiste à afficher l’app Terminal dans le Finder (vous pouvez le faire en cliquant son icône dans le Dock avec la touche ⌘), puis afficher ses informations (⌘I) et cocher la case « Ouvrir avec Rosetta ». Quittez l’app, relancez-la et Homebrew fonctionnera à nouveau. Seul problème de cette approche, tout ce que vous ferez dans le Terminal de macOS passera par la couche d’émulation x86, ce qui n’est pas optimal.
La deuxième option me semble meilleure et c’est celle que j’ai utilisée sur un Mac mini sous Apple M1. Pour installer Homebrew, vous devez modifier la ligne de commande et saisir ceci :
/usr/bin/arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
Les ajouts forcent le script d’installation à considérer que vous utilisez un Mac Intel, ce qui permet à Rosetta de s’activer. Vous devrez les utiliser pour toutes les commandes par la suite toutefois. Ainsi, pour installer l’éditeur de texte nano, vous devrez saisir :
/usr/bin/arch -x86_64 brew install nano
Et pour mettre à jour tous vos paquets :
/usr/bin/arch -x86_64 brew upgrade
C’est contraignant, mais les alias sont là pour simplifier les choses. Ajoutez un alias pour que la commande brew passe systématiquement par Rosetta :
alias brew='arch -x86_64 brew'
Et vous pourrez ensuite utiliser Homebrew normalement, ou presque. Le changement d’architecture implique que certains outils en ligne de commande ne fonctionnent plus correctement, vous trouverez une liste à cette adresse. Autre point à noter, on ne sait pas encore comment se déroulera la transition vers ARM, quand les paquets seront disponibles. L’utilitaire pourrait se charger de supprimer les versions Intel et de les remplacer pour vous automatiquement, mais il est aussi possible qu’une réinstallation manuelle soit nécessaire.
Et si vous pouvez patienter, sachez qu’une mise à jour de Homebrew est en préparation pour gérer les deux architectures de manière transparente.
Bon ben on va avoir un Terminal Apple et un iTerm2, l'un sous Rosetta et l'autre non pendant la transition. C'est logique, mais je reconnais que ce coup là je ne l'ai pas anticipé. ;)
Il est aussi possible de l’installer en natif ARM, cependant dans ce cas il y a encore beaucoup de paquets qui ne marchent pas.
Si vous vous sentez aventureux, pour l’installer en natif ARM, il faut utiliser la méthode d’installation alternative, qui recommande de l’installer dans /opt. Ça donne:
- cd /opt
- mkdir homebrew && curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew
Et ne pas oublier d’ajouter /opt/homebrew/bin à la variable d’environnement PATH.
Pour savoir ce qui fonctionne en natif ARM actuellement, voir le tableau de cette issue: https://github.com/Homebrew/brew/issues/7857
La solution la plus simple ne serait pas de définir un profil « Homebrew »* sur Terminal (ou toute autre application de terminal comme iTerm) et de définir le shell par défaut sur « /usr/bin/arch -x86_64 /bin/bash » ?
Le problème que vous soulevez ne semble pas venir du Terminal, mais du shell lui même par défaut. En faisant ainsi il n’y aurait même pas besoin de définir d’alias et de changer la ligne d’installation d’Homebrew.
Ce profil pourrait être utilisé pour toutes les commandes qui n’utilisent pas des programme ARM, voir être configuré par défaut.
@ ssssteffff :
Pas bête (mais en nommant ce profil « Rosetta » plutôt que Homebrew, puisqu’il peut servir à lancer tout exécutable Intel).
Cependant, pour mon usage j’aurais tendance à préférer la définition d’un alias « rosetta » pour pouvoir mixer facilement l’usage d’exécutables natifs et d’exécutables émulés au sein d’un shell natif.
Je trouve tout de même regrettable que la gestion de l’émulation ne soit pas aussi transparente dans le terminal que pour les applications graphiques.
Je vais laisser les betas testeurs se casser les dents dessus 🙂
Dans ma boite de devs on a des macs sous macos et des pcs sous linux et c’est assez cool au niveau des commandes.
Si demain c’est plus compliqué sur mac, ça va refroidir certains devs
@ madaniso :
Il n’y a pas de raison que ce soit plus compliqué demain. C’est aujourd’hui que c’est plus compliqué. :-)
Mais « demain » (c’est-à-dire quand la majeure partie de ce qu’on utilise aura été portée sur les nouveaux CPU), on retrouvera le même confort d’utilisation qu’auparavant.
@BeePotato
>"C’est aujourd’hui que c’est plus compliqué. :-)"
En termes de production : Not Ready For Prime Time.
@ occam : « En termes de production : Not Ready For Prime Time. »
Enfin, ça, c’est très variable selon l’usage qu’on a du Mac : pour ceux qui n’utilisent jamais les outils en ligne de commande, le souci évoqué ici n’existe pas.
Pas plus, d’ailleurs, que pour ceux qui n’utilisent en ligne de commande que des outils fournis par l’OS ou développés par eux.
@BeePotato
Logiquement, le problème ne se pose qu’à ceux qui comptent en faire usage.
Donc, à ceux qui berçaient l’illusion que le « Mac » version Apple Silicon, architecture à la performance brute remarquable et possédant le potentiel le plus débridé parmi les dessins courants, continuerait d’être un General Purpose Computing Engine au plein sens du terme.
Les extraits d’interview de Johnny Srouji publiés ici suggèrent de manière subtile mais claire que telle n’est pas l’intention :
https://om.co/2020/11/17/why-m1-chip-by-apple-matters/
S’il y a bien un orfèvre en la matière parmi ceux qu’Apple a autorisés à l’ouvrir, c’es bien Srouji. Il sait ce qu’il dit. Sa vue est par ailleurs parfaitement cohérente. Rien à redire, dans le cadre de sa perspective.
Sauf qu’il faut arrêter de prendre ce qui continue à porter désormais l’étiquette « Mac » pour des engins bidouillables.
@ occam : « Donc, à ceux qui berçaient l’illusion que le « Mac » version Apple Silicon, architecture à la performance brute remarquable et possédant le potentiel le plus débridé parmi les dessins courants, continuerait d’être un General Purpose Computing Engine au plein sens du terme. »
Gné ?
Rien pourtant n’indique que ce n’est plus le cas. Et ça l’est évidemment — forcément.
Mais bon, j’arrête là, parce que j’ai déjà pu me rendre compte que ce n’était pas la peine de tenter une quelconque discussion quand ça commence à partir dans de tels délires…
demain ce sera très simple , mais demain c'est dans 2 ans ... pas dans 24 heures
Et l'installation des Grafana, InfluxDB, node-red etc, c'est toujours possible avec les ARM ?
Hummmm ça risque d’être bloquant pour pas mal de choses j’imagine...
J’utilise un logiciel qui s’installe avec Homebrew ( AMC pour générer des QCM), et du coup je ne pourrai pas l’installer.
D’ailleurs si certaines personnes ont un mac M1 et connaissent AMC, j’aimerai bien avoir un retour!
Acheter le M1 au début, c’est se heurter à beaucoup de galères et pourquoi ? Je doute que l’autonomie soit au rdv, tant les applis arm sont rares.
On n’achète pas une v1 sous une nouvelle architecture si l’on a une utilisation un poil compliquée (lignes de commandes, logiciels très spécifiques, etc...)
Mais pour la plupart des gens, Rosetta rendra la transition invisible. Il n’y a qu’à lire les premiers tests, c’est très très prometteur.
Bonjour, Avez-vous testé MacPorts ?
De ce que je peux lire sur le github de MacPorts, ce dernier supporte, au moins partiellement, les Macs avec Apple Silicon.
Limite hors sujet: je n’ai plus le live reload avec Angular depuis Big Sur alors que ça marche avec le même projet sur Catalina.
Vraiment hors sujet en fait.
Je pense que si on utilise brew et d'autres outil en ligne de commande, on teste les changements avant de passer pour de vrai à BigSur. Je fais typiquement ce genre de switch pendant les vacances de Noël avec du temps devant moi et une possibilité de revenir en arrière si certains problèmes gênant ne sont pas surmontés.
Vu les (bonnes) suggestions des posts précédents, je verrais bien la stratégie suivante avec deux installations de brew :
- `/usr/local` avec sa commande `brew` pour les applis natives M1
- `/opt/homebrew/` avec une commande (ou alias) `brew-rosetta` pour les applis émulées
avec leurs PATH réglés pour donner priorité aux applis natives.
De cette façon l'arborescence presque vide (au début) `/usr/local/` sera réservée aux commandes native ; et l'arborescence `/opt/brew/` contiendra toutes les verrues émulées et appelées à disparaitre d'elle-même avec le temps.
Une autre solution serait peut-être que brew lui-même encapsule tout exécutable non natif dans un appel via rosetta.
Bref il y a plein de solutions possibles qui ont été oubliées à force d'avoir des systèmes homogènes. Pensez simplement à la texlive qui fait cela depuis prêt de 25 ans !
Par contre j'ai une question : si on installe les recettes de brew en les recompilant à partir des sources, je suppose qu'elle sont natives d'office et donc ne nécessite plus l'émulation non ?
-- Maurice
@mdiam
l’équipe de Homebrew recommande le contraire, c’est à dire de ne plus utilisé /usr/local pour la version ARM64, car il ne sera plus supporté officiellement dans l’avenir.
Donc il vaut mieux avoir:
- /opt/homebrew pour la version native ARM64
- /usr/local pour la version Intel