Se mai lavorerai con me ad un certo punto, devi sentirmi consigliare di utilizzare un gestore di versioni di Ruby come rbenv . Anche per quanto scrivo una guida Notion per la guida all'onboarding del nuovo ingegnere presso l'azienda con cui sto attualmente lavorando utilizzando rbenv come requisito. Ma perché preoccuparsi di usarli?

Questo articolo è più simile a un perché e a una serie di paragrafi che contengono retroscena e ragioni. Pertanto, non dovresti saltarlo e leggerlo dall'inizio alla fine invece di cercare una parte TL;DR.

Per cosa usiamo comunque Ruby come sviluppatore iOS?

Molte cose! Beh, più o meno. Ci sono molti strumenti che vengono usati come strumenti complementari o di utilità che sono scritti in Ruby, specialmente gli strumenti maturi negli ultimi anni. Ad esempio, Cocoapods e i suoi plugin. Ad un certo punto, prima che Apple decidesse di creare SPM, è lecito affermare che quasi tutti noi utilizzavamo Cocoapods come strumento principale per la gestione delle dipendenze di terze parti . Altri strumenti molto comuni da usare che vorrei menzionare sono Xcodegen e Fastlane. Sì, anche quei due sono scritti in Ruby. Così tanti strumenti e script di utilità sono scritti in Ruby. La lingua è presente come parte della tua attività quotidiana, che ti piaccia o no.

Non abbiamo già Ruby integrato nel nostro MacOS? Perché dobbiamo usarne un altro

Sì, lo facciamo. MacOS-es ha il proprio Ruby installato nella root del sistema, e sì, funziona proprio come il normale Ruby e funzionerà per la maggior parte del tempo. La parola chiave qui è la maggior parte delle volte. Di solito, la maggior parte delle persone non ha alcun problema per quanto riguarda gli strumenti basati su Ruby che sono stati menzionati in precedenza nel loro lavoro quotidiano. Ma fino a un piccolo intoppo iniziato qualche anno fa. La nuova era del silicio Apple.

Apple Silicon, arm64 e gemme Ruby obsolete.

A causa della differenza nel tipo di architettura utilizzata dal nuovo Macbook, l'architettura basata su Apple Silicon arm64, molte gemme Ruby obsolete dovevano essere supportate in modo nativo. Così tante persone che sono nuove a questo tipo di problema stanno cercando su Google StackOverflow e seguendo la soluzione di usare Rosseta2 o aggiungendo il parametro -arch x86_64 alla loro esecuzione terminale. Che... non mi piace!

Più la tua base di codice si basa su strumenti basati su strumenti Ruby gems, più è probabile che tu abbia questo problema.

Ma cosa succederebbe se ti dicessi che quelle gemme Ruby non sono sempre obsolete e non mantenute. La maggior parte di quelle gemme rotte ha rilasciato il supporto aggiornato per l'architettura arm64. Possono essere eseguiti in modo nativo su Apple Silicon! Non serve più Rosseta!

L'unica cosa di cui queste gemme di solito hanno bisogno è di essere eseguite con la versione più recente di Ruby 3.xx invece della versione 2.6.x integrata.

Invece di fare affidamento su Rosetta come soluzione irregolare, preferisco eseguire i miei strumenti su un 3.x. x istanza di Ruby.

Allora perché non aggiorniamo Ruby del nostro MacOS?

Sappiamo già che l'istanza Ruby integrata è posizionata nelle nostre radici di sistema , situata in /usr/bin/ruby, che è l'utente root, ovvero il superutente di sistema.

Questo è il motivo per cui ogni volta che provi a installare un nuovo gem a livello globale, devi usare sudo nei tuoi comandi. Probabilmente, questa pratica può portare a un problema di sicurezza indesiderato se non si presta attenzione.

Con questo approccio, non devo mai usare sudo ogni volta che voglio installare gemme Ruby aggiuntive.

Apple ha anche motivi per non spedire la nuova istanza di Ruby nel suo macOS che non conosciamo. Voglio garantire che la stabilità di macOS sia mantenuta, quindi è meglio se facciamo qualcosa al di fuori dell'istanza ruby ​​root del sistema e facciamo tutte le nostre esigenze, come l'aggiornamento e l'installazione di gemme Ruby aggiuntive in quella posizione.

Cambia versione di Ruby ogni volta che ne hai bisogno (aggiuntivo)

Il punto precedente menziona già che ti risparmia il mal di testa nel gestire le tue gemme non funzionanti da utilizzare con una macchina Apple Silicon senza emulazione rosetta. Per la maggior parte delle persone, è sufficiente convincerli a utilizzare un gestore delle versioni di Ruby. Ma nel mio caso, dal momento che mi occupo del flusso di lavoro CI/CD iOS e "aiuto" altri ingegneri a gestire questo tipo di cose (risoluzione dei problemi degli strumenti). Spesso ho bisogno di flessibilità nei miei ambienti Ruby. Ad esempio, il server Xcode CI utilizza ancora una versione 2.6.x (e nel mio caso funziona bene poiché è ancora una macchina Intel), a volte devo trovarmi a passare a versioni simili sulla mia macchina per renderlo semplice sulla configurazione del bundle Gemlock.file. O a volte, Ho bisogno di installare una nuova istanza di Ruby per emulare e verificare se un nuovo membro con un computer pulito può seguire la nostra guida all'onboarding. Avere un gestore delle versioni di Ruby può aiutare con questo genere di cose.

Passaggi per utilizzare e installare rbenv

Userò rbenv come gestore della versione Ruby di mia scelta. Puoi utilizzare qualsiasi altro tipo di gestore delle versioni di Ruby per ottenere i vantaggi menzionati in precedenza.

1. Installa Homebrew copiandolo e incollandolo nel tuo terminale.

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

brew install rbenv ruby-build

rbenv install 3.1.1
rbenv global 3.1.1

Conclusione

Supponiamo che tu abbia problemi o non riesca a realizzare alcuni dei tuoi ruby ​​gem / toolings nel tuo sviluppo iOS giorno per giorno a causa della macchina Apple Silicon e sei costretto a utilizzare Rosetta nel tuo terminale. In tal caso, puoi provare a seguire questo articolo, stare lontano dal Ruby integrato nelle radici di sistema del tuo macOS e divertirti a stare lontano da sudo completamente.

Saluti!