Qual è la tua recensione di Homebrew (software)?

A2A.

Questo è difficile da rispondere per me. Vorrei davvero che mi piacesse, ma ha un sacco di cose che considererei difetti fatali.

Rendete conto che un software come Homebrew è destinato principalmente agli sviluppatori di software a riga di comando, e quindi è inteso principalmente come un mezzo per estendere l'ambiente di sviluppo di uno sviluppatore di software.

E' bravo a farlo. Riesce anche a fare bene alcune cose che altre cose (per esempio MacPorts) sbagliano, come impacchettare i pacchetti in una gerarchia di installazione, e poi installarli tramite link simbolico, invece di installarli direttamente.

Perché questo esempio...

Ho scelto questo esempio in particolare, poiché recentemente ho scritto una risposta che tratta di come ho impostato i sistemi Mac OS X per sviluppatori di modalità che uso personalmente per sviluppare software. Una delle cose principali è che ho una partizione dati separata su cui vive il mio account utente, e tendo a installare le mie applicazioni lì, invece di installarle sulla partizione di avvio del sistema operativo, perché tendo a portare in giro un paio di partizioni di avvio allo stesso tempo.

In realtà mi porto dietro 4 o più partizioni di boot quando faccio lavoro sul kernel, cosa che facevo soprattutto quando lavoravo alla Apple, perché dovevo avere una partizione per la release corrente, una per la prossima release (che è quella su cui lavoravo principalmente tutto il tempo), e una per la release successiva a quella corrente, in modo da poter correggere i bug del kernel e della sicurezza (per il prossimo aggiornamento software). Potrei anche portarmene dietro un altro paio per un confronto A/B su "avvia questa partizione per ottenere il kernel con la correzione"/"avvia quella partizione per ottenere il kernel senza la correzione".

Utilizzando l'approccio symlink, è effettivamente possibile mettere tutto sulla partizione dati, e poi fare un symlink in ciascuna delle partizioni di avvio.

Ma sapete cosa? Potete farlo anche con MacPorts. Perché /usr/local non esiste di default, quindi potrebbe anche essere un link simbolico a una directory sulla partizione dati, e poi non sto copiando in giro gli alberi di link simbolici di Homebrew in un /usr/local su ogni partizione di avvio.

Quindi cosa intendevo esattamente con "fa alcune cose bene"?

Primariamente, mette il numero di versione nella directory in cui l'immagine è costruita, così ho il numero di versione della cosa che sto usando, e posso scegliere tra le versioni.

Aggiungendo questo livello di astrazione, Homebrew mi protegge da cose che potrebbero essere confuse in base al numero di versione.

Per esempio, usando MacPorts, potrei includere i file header di una libreria versione 1.5.11 quando costruisco qualcosa, e poi qualche altro pacchetto installa la libreria versione 1.7.2, e quindi finisco per usare la libreria sbagliata con i file header sbagliati.

Questo non succede con Homebrew.

Assumendo che la "ricetta" per la libreria in entrambi i casi sia corretta, e anche le "ricette" per le cose che usano la libreria siano sufficientemente dettagliate. E la "ricetta" per la cosa stessa bypassa o applica una patch a GNU configure per la cosa che si sta costruendo, in modo tale che tutti i riferimenti alla libreria e all'header siano relativamente radicati, e possa specificare i numeri di versione.

Si tratta di una grande quantità di supposizioni, ma quando funziona, è una cosa di una bellezza spettacolare.

Inversamente, quando non funziona, è anche piuttosto spettacolare. Non in senso buono.

Ma mi piace l'astrazione, che rende ciò che è apparentemente installato una visione più piccola su ciò che è stato effettivamente costruito o meno. La vista può corrispondere esattamente ad essa, o la vista può essere una finestra molto più piccola su una cosa molto più grande.

Homebrew ha anche un paio di difetti piuttosto brutti.

Se voglio sviluppare un software che è basato su un certo numero di componenti Open Source, Homebrew praticamente non mi aiuta in questo. Posso svilupparlo all'interno della gerarchia, e fare un symlink per accedervi, ma non è davvero qualcosa che ho intenzione di integrare, per esempio, in un progetto XCode.

Ironicamente: MacPorts è più utile lì ... a modo suo ... ma in entrambi i casi, sono bloccato a collegare staticamente le librerie in un enorme binario.

Homebrew finisce per essere utile per ottenere strumenti per uno sviluppatore, ma non è grande in nessun altro modo, e per lo più non ho bisogno degli strumenti che Homebrew ottiene per me, a meno che non ne sia già dipendente.

Se venite da un ambiente Linux, e state facendo un progetto una tantum o due volte su Mac OS X, e non state usando l'IDE che viene fornito con XCode per fare la maggior parte del vostro lavoro, allora Homebrew è probabilmente un buon modo per ottenere gli strumenti a riga di comando che siete abituati ad usare su Linux. O BSD, se sei il tipo che installa un sacco di porte su un sistema BSD.

Oppure potresti semplicemente collegare symlink /usr/local in una sottodirectory da qualche parte, e usare MacPorts. O l'uno o l'altro.

Cosa penso sia il problema irrisolto?

Quello che manca per quasi tutto l'Open Source è un gestore di componenti.

Si finisce con cose come MacPorts e Homebrew quando si cerca di implementare un gestore di pacchetti.

Mentre un gestore di pacchetti può installare un componente (o anche costruire il componente - molti gestori di pacchetti sono anche gestori di configurazione), è piuttosto scadente nel gestire componenti.

Se si ottiene qualcosa come il sistema di porte di FreeBSD, che è un'estensione del sistema di compilazione di FreeBSD, allora si finisce per ottenere un gestore di pacchetti, un gestore di configurazione e un ambiente di cross-build.

Linux è piuttosto povero nel fornire un ambiente di cross-build, che è importante, se si vuole, per esempio, compilare su Linux, ma puntare ad ARM. È possibile farlo, ma un sacco di GNU configure usa prodotti di build per elaborare il codice sorgente in altri prodotti di build (l'albero dei dispositivi del kernel per i sistemi ARM/PPC, e per il kernel stesso, ma anche - separatamente, senza una buona ragione - per CoreBoot, è un buon esempio qui).

Nessuno fornisce un gestore di componenti.

XCode in qualche modo lo fa. Eclipse può, se si trova un mucchio di plugin oscuri - e quindi si rinuncia a usare alcuni plugin veramente utili che non possono essere cross-target (assumendo che si stia usando un linguaggio che compila per una specifica architettura o microarchitettura, invece di Bytecode, come Java). Anche Microsoft Visual Studio può farlo, ma la maggior parte dei componenti di terze parti non sono disponibili come sorgente, e non sono stati compilati per ARM o altre architetture.

Per risolvere questo problema sarebbe necessario prendere un'enorme quantità di progetti Open Source, e se non proprio biforcarli, approfondirli abbastanza da permettervi di inserire le vostre parti di component manager come parte del progetto stesso.

Se voglio creare un ambiente di sviluppo, e mancano dei pezzi? Personalmente correggo solo i 4 o 5 bug di portabilità in bsd.ports.mk, e lo faccio. Ci sono solo pochi strumenti che uso oltre a quelli che sono installati di default quando installo XCode e gli strumenti della linea di comando di XCode.

Se ho qualcuno che viene da Linux, e vuole un mucchio di strumenti (ma è disposto a lavorare con le librerie - anche quelle Open Source! - dall'interno dell'IDE di XCode, allora consiglio Homebrew. È come "apt" per Linux.

Se hanno intenzione di insistere sul collegamento statico di un mucchio di roba, e sono disposti a costruire le librerie nel loro ambiente di compilazione (e non consiglio mai e poi mai di farlo: rende le vostre compilazioni riproducibili byte-per-byte come, diciamo, Debian Linux con package retry, invece di dipendenze correttamente specificate), allora alzo le mani e suggerisco di andare con MacPorts.

Tutto sommato?

Se sei uno sviluppatore proveniente da Linux che vuole un mucchio di strumenti, come (per esempio) l'ultima versione di Emacs, e se usi componenti Open Source nel tuo progetto ma gestisci le loro build all'interno di XCode - allora Homebrew è probabilmente per te.