Come installare Brew su WSL in Windows

Brew su WSL: cosa stai davvero installando

Su WSL non stai installando un pacchetto “nativo di Windows”, ma Homebrew dentro la distribuzione Linux. La differenza conta: Brew vive nel filesystem della distro, usa i binari e le librerie di Linux, e non deve essere confuso con gli strumenti di Windows installati sul disco host. Se questo confine resta chiaro, l’installazione è lineare; se lo forzi, inizi a vedere path sporchi, conflitti di shell e comportamenti difficili da diagnosticare.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Il caso d’uso tipico è semplice: vuoi un gestore di pacchetti moderno dentro Ubuntu, Debian o altre distro su WSL per sviluppare, testare tool CLI o allinearti a un flusso già usato su macOS e Linux. Il punto non è “portare Brew su Windows”, ma usare Brew nel tuo ambiente Linux sotto WSL con una configurazione pulita e ripetibile.

Prerequisiti che evitano metà dei problemi

Prima di toccare l’installazione, verifica tre cose: la distro è aggiornata, la shell è quella giusta e la rete funziona dentro WSL. Sono controlli banali, ma sono quelli che distinguono un setup pulito da una sessione di troubleshooting inutile.

1. Apri la distro WSL e controlla la versione.
2. Aggiorna i pacchetti base della distro.
3. Verifica che la risoluzione DNS e l’uscita HTTPS funzionino dalla shell Linux.

Esegui questi comandi dentro WSL:

uname -a
cat /etc/os-release
sudo apt update
curl -I https://github.com

Se curl -I fallisce con timeout o errore di risoluzione, non è un problema di Brew: è un problema di connettività della distro o della configurazione di rete WSL. Sistemarlo prima evita di attribuire a Brew un guasto che non gli appartiene.

Installazione corretta di Homebrew dentro WSL

La procedura ufficiale di Brew su Linux è anche la base corretta su WSL. L’installazione va fatta come utente normale, non come root. Brew crea la propria directory, gestisce permessi e path in modo autonomo, e l’uso di sudo durante l’installazione è uno dei modi più veloci per ottenere una configurazione scomoda da mantenere.

1. Apri la shell della distro WSL.
2. Esegui lo script di installazione ufficiale di Homebrew.
3. Segui le istruzioni finali per aggiungere Brew al PATH.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Alla fine dello script, Homebrew mostra un blocco da copiare nella shell. Su Linux e WSL il percorso tipico è uno di questi:

eval "$($(brew --prefix)/bin/brew shellenv)"

oppure, più spesso, una riga del tipo:

eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

Il punto operativo è questo: non copiare a memoria il comando, copia esattamente quello proposto dall’installer nella tua sessione. Il percorso cambia in base a come Brew è stato posizionato e al tipo di installazione rilevata.

Rendere Brew persistente senza sporcare la shell

Dopo l’installazione, devi fare in modo che Brew sia disponibile a ogni apertura della shell. Su WSL la scelta più pratica è aggiungere il bootstrap nel file di inizializzazione della shell usata davvero, non in un file “generico” che magari non viene letto. In pratica: ~/.bashrc per Bash, ~/.zshrc per Zsh.

1. Identifica la shell corrente con echo $SHELL.
2. Apri il file di init corretto.
3. Aggiungi la riga suggerita da Brew per il suo environment.
4. Ricarica la shell e verifica il comando brew.

echo $SHELL
nano ~/.bashrc

Un esempio tipico per Bash è questo:

eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

Se usi Zsh, la stessa riga va in ~/.zshrc. Dopo il salvataggio:

source ~/.bashrc
brew --version
which brew

Il controllo utile non è solo che brew --version risponda, ma che which brew punti alla directory gestita da Homebrew e non a un wrapper o a un binario residuo da un tentativo precedente.

Verifica del layer WSL: il problema non è sempre Brew

Quando Brew non si installa o non scarica formule, il primo sospetto dovrebbe essere la rete dentro WSL, non il gestore pacchetti. WSL può avere DNS diversi da Windows, proxy non propagati, o una configurazione temporanea che cambia dopo il riavvio della distro. Questo è il classico punto in cui si perde tempo a guardare il sintomo e non il layer giusto.

1. Controlla il DNS risolto dalla distro con resolvectl se disponibile, oppure con un test diretto su un host pubblico.
2. Verifica HTTPS verso GitHub e i mirror usati da Brew.
3. Se sei dietro proxy aziendale, controlla le variabili d’ambiente nella shell Linux.

getent hosts github.com
curl -I https://github.com
env | grep -i proxy

Se il DNS risolve ma curl fallisce, il problema può essere TLS, proxy o filtraggio. Se invece non risolve, la causa è quasi sempre a livello di rete WSL o DNS impostato male. In entrambi i casi, fermati lì: non ha senso riprovare l’installazione di Brew finché la distro non esce verso Internet in modo affidabile.

Pacchetti di base utili subito dopo l’installazione

Una volta che Brew è operativo, il primo giro non dovrebbe essere “installo tutto”. Meglio partire da pochi strumenti di controllo: un editor, un downloader, un visualizzatore di processi e, se ti serve, una versione aggiornata di Git. L’obiettivo è verificare che il flusso installa-esegui-rimuovi funzioni senza interferenze con i pacchetti della distro.

1. Installa un tool semplice, ad esempio wget o htop.
2. Controlla che il binario venga risolto da Brew.
3. Confronta il comportamento con il pacchetto della distro solo se ti serve capire precedenze nel PATH.

brew install htop
brew list
which htop
htop --version

Su WSL questo è utile anche per un altro motivo: ti dice subito se il filesystem e l’esecuzione dei binari sono sani. Se un pacchetto si installa ma non parte, il problema non è più la rete; può essere una dipendenza mancante, un alias, un path errato o un conflitto con un comando già presente nella distro.

Conflitti tra Brew, apt e PATH

Il problema più comune dopo l’installazione non è Brew in sé, ma il fatto che il sistema trova prima un binario installato con apt o un alias di shell. In pratica, credi di lanciare il tool appena installato, ma in realtà stai eseguendo una versione diversa. Questo succede spesso con git, python, node e utility di rete.

1. Controlla la risoluzione con type -a nomecomando.
2. Verifica il path effettivo con which nomecomando.
3. Se serve, rivedi l’ordine del PATH nella shell.

type -a git
which git
echo $PATH

Se Brew deve prevalere, il suo environment va caricato prima dei path di sistema che rischiano di “rubare” il comando. Se invece vuoi mantenere il pacchetto della distro e usare Brew solo per tool aggiuntivi, lascia l’ordine com’è e limita Brew ai binari che non entrano in conflitto.

Integrazione con Windows: utile, ma non sempre

Uno degli errori più frequenti è trattare WSL come se fosse una cartella di Windows con una shell diversa. Non lo è. Puoi comunque accedere ai file di Windows, lanciare eseguibili Windows e passare dati tra i due mondi, ma per Brew è quasi sempre meglio restare nel perimetro Linux. Mischiare troppo i due ambienti porta a path lunghi, performance peggiori e strumenti che si comportano in modo incoerente.

Se devi aprire un file prodotto da Brew con un editor Windows, fallo esplicitamente. Se devi usare una utility Windows da WSL, chiamala in modo chiaro. Non lasciare che il sistema scelga da solo quale lato deve vincere, perché è lì che iniziano i casi ambigui da supporto tecnico.

/mnt/c/Windows/System32/notepad.exe ~/.bashrc

Questo non è un invito a costruire workflow ibridi per forza. È solo il modo corretto di evitare che Windows e Linux si pestino i piedi quando la configurazione cresce.

Quando Brew su WSL non conviene

Non tutti i casi d’uso giustificano Brew. Se ti serve solo qualche pacchetto standard già presente nei repository della distro, apt è spesso più semplice da mantenere. Se invece vuoi versioni aggiornate, tool di sviluppo non presenti nei repo o una gestione più uniforme tra ambienti diversi, Brew ha senso. La scelta corretta dipende dal problema, non dalla moda del momento.

1. Usa apt per i componenti base della distro e per ciò che deve integrarsi con il sistema.
2. Usa Brew per tool user-space e versioni più fresche.
3. Evita di installare lo stesso software in due gestori diversi senza una ragione precisa.

Un esempio pratico: se ti serve git solo per clonare repository e lavorare in shell, Brew può andare bene. Se invece stai costruendo una macchina che deve essere mantenuta da più operatori, con policy di patching e audit chiari, la scelta del gestore va standardizzata per evitare confusione operativa.

Diagnostica rapida quando qualcosa non torna

Se Brew è installato ma si comporta male, raccogli evidenza prima di cambiare altro. In WSL la diagnosi utile passa da pochi comandi: stato della shell, path, rete, versione della distro e log del bootstrap se l’installazione è fallita. Non serve fare magie; serve guardare i punti che spiegano il comportamento osservato.

brew doctor
brew config
uname -r
cat /etc/os-release
journalctl --user -n 50 --no-pager 2>/dev/null

brew doctor è utile, ma non è un oracolo. Ti segnala problemi noti e alcune incoerenze di setup, però non sostituisce il controllo del contesto: path, permessi, rete e shell effettiva. Se brew doctor è pulito ma il comando continua a non funzionare, il problema è quasi sempre fuori da Brew.

Assetto consigliato per un setup stabile

La configurazione che regge meglio nel tempo è questa: WSL aggiornato, distro Linux pulita, Brew installato come utente normale, path caricato nella shell giusta e pochi pacchetti scelti con criterio. Non serve complicare. Serve che ogni strato faccia il suo lavoro senza invadere quello sopra o sotto.

1. Conferma che la distro WSL usata sia quella di lavoro e non una seconda installazione dimenticata.
2. Inserisci la riga di brew shellenv nel file di init corretto.
3. Testa rete, installazione e risoluzione comandi con un pacchetto piccolo.
4. Documenta eventuali eccezioni di PATH o proxy per evitare regressioni future.

Se devi consegnare questa configurazione a un team, aggiungi anche una nota operativa: quale shell usare, quali pacchetti sono gestiti da Brew e quali restano a apt, e dove guardare in caso di errore. È il modo più semplice per evitare che ogni operatore reinventi la stessa diagnosi da zero.

Checklist finale da tenere sotto mano

Prima di considerare chiusa l’installazione, verifica questi punti in ordine: brew --version risponde, which brew punta al path previsto, brew doctor non segnala problemi bloccanti, curl -I https://github.com funziona dalla distro e il pacchetto test installato si esegue correttamente. Se uno di questi punti fallisce, il problema è ancora aperto e va chiuso sul layer giusto.

In sintesi: Brew su WSL funziona bene quando lo tratti come un tool Linux dentro una distro Linux, non come un componente di Windows. Questa distinzione evita quasi tutti gli errori pratici: path confusi, permessi sbagliati, dipendenze mancanti e diagnosi fuorvianti.