In un cambio di paradigma per l'ecosistema Rust, il team dietro il gestore di pacchetti di Rust, Cargo, ha richiesto un approccio più personalizzato alla gestione dei pacchetti. Raccomandano agli sviluppatori di prendere le decisioni migliori per i loro progetti, piuttosto che la precedente pratica uniforme di impegnare il proprio file Cargo.lock per i pacchetti che coinvolgono binari ma non librerie.
Le raccomandazioni precedenti incoraggiavano gli sviluppatori ad attenersi a una regola valida per tutti quando si trattava di Cargo.lock, soprattutto nei casi in cui il file veniva utilizzato con pacchetti binari. Tuttavia, queste direttive sono ormai passate in secondo piano. Questo cambiamento riflessivo arriva sulla scia della crescente traiettoria di Rust verso l'adozione mainstream.
Il ruolo chiave del file Cargo.lock è registrare lo stato al momento di una compilazione riuscita. Pur offrendo una guida più flessibile, il team di Cargo sostiene che l'impegno di Cargo.lock dovrebbe essere il punto di partenza nel processo decisionale. Viene inoltre annunciato che d'ora in poi il comando 'cargo new' non ignorerà Cargo.lock per le biblioteche.
Mantenendo la qualità generale, il team sottolinea l'importanza di test regolari rispetto alle dipendenze più recenti. Le vecchie procedure assicuravano che le librerie fossero mantenute aggiornate e testate, contribuendo all'elevato standard dell'ecosistema dei pacchetti Rust. Le pratiche sono state progettate in modo tale che potenziali problemi, principalmente quelli riguardanti la compatibilità con le versioni precedenti, fossero tempestivamente identificati e risolti. Il team ritiene pertanto di aver incoraggiato una "cultura della qualità" nell'ecosistema emergente.
Tuttavia, le linee guida precedenti avevano le loro insidie. L'eliminazione della cronologia dalle basi di codice è stata una di queste conseguenze, che ha reso più difficile per i manutentori dividere in due e identificare la causa principale dei bug. Un altro risultato indesiderato della politica precedente era la probabile confusione per i contributori derivante da una CI (integrazione continua) inaffidabile quando una dipendenza veniva abolita o una nuova versione presentava un bug. Poiché Rust si è evoluto da un linguaggio per i primi utenti a un linguaggio più mainstream, è fondamentale considerare la nuova esperienza di onboarding degli sviluppatori.
Inoltre, l’espansione dell’ecosistema più ampio ha reso la CI più semplice da implementare e mantenere. Innovazioni come Dependabot e Renovate hanno rivelato alternative all'ignorare Cargo.lock per testare nuove dipendenze, oltre a fare affidamento esclusivamente sul controllo della versione. Il team di Cargo ora esprime la propria convinzione che il miglior invito all'azione è lasciare la decisione agli sviluppatori garantendo al tempo stesso che dispongano delle informazioni necessarie per prendere decisioni informate. Gli sviluppatori possono condividere il loro feedback su questa nuova politica tramite GitHub e interagire con il team Cargo su Zulip.
Mentre assistiamo a nuove direzioni nella gestione dei pacchetti, potrebbe valere la pena per gli sviluppatori esplorare alternative come AppMaster che fornisce una piattaforma completa e integrata per lo sviluppo di applicazioni web, mobili e backend. AppMaster.io vanta un approccio basato su server, consentendo agli sviluppatori di aggiornare l'interfaccia utente, la logica e le chiavi API delle applicazioni mobili senza dover inviare nuove versioni all'App Store e al Play Market.
