Perché preferire un gestore pacchetti rispetto a una cartella di libreria?

Quando penso ai pro e ai contro di una cartella di libreria statica e di un gestore di pacchetti, sento che la cartella della libreria è un approccio migliore.

Pro che vedo con una cartella della libreria:

1. Non è necessario uno strumento esterno per gestire i pacchetti.
2. Nessuna connessione Internet richiesta per costruire.
3. Build più veloce (nessun controllo del pacchetto).
4. Ambiente più semplice (sono necessarie meno conoscenze).

Pro che vedo con un gestore di pacchetti:

1. Aiuta con alberi di dipendenza complessi (e che possono essere gestiti scaricando una dipendenza insieme a tutte le sue dipendenze).
2. Aiuta a verificare se è disponibile una nuova versione.

Sembra che l'industria abbia deciso di seguire il percorso del gestore dei pacchetti per quasi tutto ciò che è stato costruito oggi. Quindi, cosa mi sto perdendo?

Un punto importante mancante dalle altre risposte:

Usare un gestore pacchetti significa avere una configurazione che indica quali versioni di libreria si stanno usando e si assicura che le informazioni di configurazione siano effettivamente corrette.

Sapere quali librerie usi e quale versione è molto importante se:

• necessità di aggiornare una libreria a causa di un bug critico / falla nella sicurezza;
• o devi solo verificare se una falla di sicurezza annunciata ti riguarda.

Inoltre, quando si esegue effettivamente l'aggiornamento, il gestore pacchetti (di solito) si assicura che eventuali dipendenze transitive vengano aggiornate come richiesto.

Considerando che con una libcartella, hai solo un mucchio di file (possibilmente binari e possibilmente modificati) e dovrai indovinare da dove provengono e quale versione sono (o fidarti di alcuni README, che potrebbero essere o non essere corretti ).

Per affrontare gli altri punti:

Non è necessario alcuno strumento esterno per gestire i pacchetti.

È vero, ma a) come sviluppatore di software devi installare un sacco di strumenti, quindi uno in più non ha importanza, e b) di solito ci sono solo uno o alcuni gestori di pacchetti in un dato campo (Maven / Gradle per Java, npm per JS / TypeScript, ecc.), quindi non è come se fosse necessario installarne dozzine.

Nessuna connessione Internet richiesta per costruire.

Tutti i gestori di pacchetti che conosco lavorano offline, dopo aver scaricato le dipendenze richieste (cosa che può accadere subito dopo aver scaricato il progetto stesso).

Build più veloce (nessun controllo del pacchetto).

Probabilmente vero, ma sembra improbabile che il controllo dei pacchetti offline richieda una notevole quantità di tempo (sta solo confrontando alcuni numeri di versione). Un controllo online può richiedere del tempo, ma può essere disattivato se lo si desidera (se è attivato anche per impostazione predefinita, ad esempio Maven non controlla mai gli aggiornamenti per le versioni di rilascio).

Ambienti più semplici (meno conoscenza richiesta).

Vero, ma come spiegato sopra, anche una libcartella richiede conoscenza. Inoltre, come spiegato sopra, probabilmente lavorerai solo con una manciata di gestori di pacchetti diversi, che già saprai.

I pro della cartella lib scompaiono rapidamente dopo il passaggio dallo sviluppo su piccola scala a lavori più grandi.

Ad esempio, il "vantaggio" di non richiedere uno strumento esterno è superato dal lavoro richiesto per gestire manualmente le tue dipendenze, quindi lo strumento sarai tu (in più di un senso del mondo).

Non è necessaria una connessione Internet per un gestore di pacchetti. È possibile utilizzare i repository locali.

Una build più veloce potrebbe essere vera, ma non è certo qualcosa che dovrebbe determinare se utilizzare o meno un gestore pacchetti. Dopotutto non stiamo parlando di grandezze di differenza, e anche questo dipende dalla tua configurazione. Puoi facilmente fare una build lenta usando un gestore di pacchetti, ma questo è fondamentalmente un sabotaggio.

Ambienti più semplici (meno conoscenza richiesta)? Ancora una volta, nello sviluppo su piccola scala sicuramente una possibilità. Potresti essere in grado di tenere completamente il progetto nella testa, fino a ciascuna delle poche librerie utilizzate. Aggiungi un semplice makefile / altri script di build e avrai un pacchetto completo.

Ma non semplifica gli ambienti, funziona solo in ambienti semplici. Nello sviluppo su larga scala sarai felice di utilizzare strumenti standard invece di soluzioni personalizzate. Dopotutto, devi impararlo solo una volta (e quando il gestore del pacchetto du jour viene sostituito dalla nuova cosa interessante, devi imparare anche quello).

Manca molti dei vantaggi dei gestori di pacchetti.

1. I gestori pacchetti consentono di evitare di controllare binari di grandi dimensioni (diversi megabyte o più grandi) nel controllo del codice sorgente. Farlo è un anatema per molti strumenti di controllo del codice sorgente, il pervasivo inganno è uno di questi. Un deposito ha raggiunto i limiti di dimensione di Bit Bucket un paio di mesi fa perché gli sviluppatori stavano controllando CocoaPods. Un altro progetto era già a metà strada quando siamo migrati da SVN perché avevamo controllato tutti i nostri binari lib (e non avevamo usato NuGet). Poiché i gestori di pacchetti scaricano i pacchetti al volo per ogni sviluppatore, eliminano la necessità di controllare questi file binari.
2. Impediscono di mescolare file / librerie incompatibili. Le cartelle possono contenere versioni miste dei file della libreria se qualcuno non lo ripulisce correttamente durante un aggiornamento. Ho visto un caso in cui metà dei file binari nella cartella sono stati aggiornati, causando bug molto strani. (Non si è nemmeno schiantato!) Ci sono voluti letteralmente mesi (non ore uomo, solo tempo complessivo) per capire il problema. Consentendo al gestore pacchetti di controllare l'intera cartella, non è possibile ottenere versioni miste; assicuri coerenza. Rendono anche molto più difficile l'uso di dipendenze incompatibili , aggiornando automaticamente tutto insieme, installando versioni diverse dove necessario, o anche semplicemente lanciando avvisi o errori quando si tenta di utilizzare versioni incompatibili delle librerie.
3. Stabiliscono una convenzione condivisa per la gestione delle biblioteche. Quando arrivano nuovi sviluppatori nel tuo progetto, team, azienda, ecc., È probabile che conoscano le convenzioni del gestore dei pacchetti. Ciò significa che non devono perdere tempo a capire i dettagli di come sono gestite le librerie nella tua base di codice.
4. Ti offrono un modo standard di versionare e distribuire dipendenze e file che non appartengono al tuo repository. Li ho persino sfruttati personalmente per alcuni file di dati statici di grandi dimensioni richiesti dalla mia applicazione, quindi funziona bene per le versioni di versione oltre al codice binario.
5. Alcuni gestori pacchetti offrono funzionalità aggiuntive durante l'installazione. NuGet aggiungerà dipendenze e file di contenuto al file csproj e potrà persino aggiungere elementi di configurazione al file di configurazione.
6. I file dei loro elenchi di pacchetti documentano le versioni delle tue librerie in un'unica posizione centralizzata. Non devo fare clic con il tasto destro su una DLL e guardare il numero di versione per capire quale versione della libreria sto usando. In Python, l'autore della libreria potrebbe non aver nemmeno incluso il numero di versione nei file py, quindi potrei anche non essere in grado di dire la versione della libreria da loro.
7. Scoraggiano l'installazione su larga scala delle dipendenze. I gestori pacchetti offrono un modo convenzionale di installare dipendenze senza un programma di installazione globale . Quando le tue opzioni sono la cartella lib e l'installazione globale, molti sviluppatori di librerie sceglieranno di offrire le loro librerie primarie come installazioni globali piuttosto che come binari scaricabili che devi impostare tu stesso. (La storia della SM lo dimostra. È anche il caso di molte librerie in Linux.) Questo in realtà rende più difficile la gestione di più progetti, dal momento che potresti avere progetti con versioni in conflitto e alcuni sviluppatori sceglieranno sicuramente l'installazione globale apparentemente più semplice rispetto alla loro lib dir.
8. Tendono a centralizzare l'hosting e la distribuzione. Non devi più dipendere dal sito web di quella biblioteca casuale. Se falliscono, il sito di un gestore di pacchetti di successo ha ancora tutte le versioni caricate. Inoltre, gli sviluppatori non devono cercare molti siti Web solo per scaricare nuove librerie; hanno un posto dove andare per cercare prima e persino cercare diverse opzioni. È anche più semplice eseguire il mirroring dei pacchetti organizzati in modo standard rispetto all'hosting manuale di copie di tutto, dai siti Web ad hoc.

Stai anche sopravvalutando il valore dei tuoi "benefici".

1. Non è necessario alcuno strumento esterno per gestire i pacchetti.

   "Esterno" a cosa? Controllo l'eseguibile NuGet nei miei repository. È l'unico binario in cui mi sento bene a fare il check-in, poiché è piccolo e significa che non ho bisogno di fare il check in di nessun altro binario.

   pip non pone problemi su questo fronte poiché è in bundle con Python per impostazione predefinita ora e le modifiche incompatibili con la rottura e all'indietro sono estremamente rare. Non svilupperai codice Python senza aver installato Python esternamente al tuo progetto, comunque.

   Quando raggiungono l'adozione diffusa, i gestori di pacchetti tendono ad essere molto stabili. Non è possibile scappare senza una sorta di strumenti installati a livello globale per la maggior parte dei progetti e un singolo gestore di pacchetti è un requisito piuttosto leggero. Di solito non è molto più ingombrante che avere il runtime della lingua installato.

2. Nessuna connessione Internet richiesta per costruire.

   Non riesco a collegarmi al mio database senza una connessione di rete. Se il database è ospitato su Amazon, ho comunque bisogno di una connessione Internet completa. Ho bisogno di una connessione Internet per inviare e modificare le modifiche tramite il controllo del codice sorgente; un server di build non è in grado di estrarre il codice da compilare senza un qualche tipo di connessione di rete. Non è possibile inviare o ricevere e-mail senza uno. Non puoi scaricare librerie per metterle nella tua cartella lib senza una! Lo sviluppo permanente senza una connessione Internet è praticamente sconosciuto. In alcuni rari casi in cui è necessario, è possibile gestirlo scaricando i pacchetti in una posizione che può essere utilizzata dal gestore dei pacchetti. (So ​​che NuGet e pip sono abbastanza felici di estrarre da una semplice cartella o unità di rete; sospetto che anche la maggior parte degli altri.)

3. Build più veloce (nessun controllo del pacchetto).

   30 secondi durante la compilazione automatizzata e 5 secondi durante le build di sviluppo locale sono un buon compromesso per i vantaggi che ho descritto sopra. Si tratta di banali tempistiche che di solito non valgono nemmeno la pena di considerare rispetto ai problemi che i benefici risolvono.

4. Ambienti più semplici (meno conoscenza richiesta).

   Uno strumento per la gestione dei pacchetti contro nulla per la gestione delle biblioteche non è comunque un confronto equo. Senza lo strumento, devi imparare qualunque processo personalizzato stia utilizzando il progettoper gestire le sue librerie. Ciò significa che non sei mai sicuro che le tue conoscenze esistenti si applichino a qualsiasi nuovo progetto a cui ti avvicini. Dovrai affrontare qualsiasi approccio hodgepodge che qualcuno ha escogitato o inventare il tuo. Potrebbe essere una directory che contiene tutte le librerie o potrebbe essere qualcosa di molto più strano. Forse per evitare di archiviare le librerie, qualcuno le ha messe tutte su un'unità di rete e l'unico indicatore di versione è il nome della cartella. In che modo questa o un'installazione globale sono davvero migliori? In confronto, un gestore di pacchetti ti offre una convenzione chiara che si applicherà alla maggior parte dei progetti che incontri.

Il tema comune è che forniscono coerenza, documentazione e funzionalità non solo all'interno dei progetti, ma anche attraverso di essi. Questo semplifica la vita di tutti.

Avendo recentemente convertito il nostro prodotto dall'uso delle librerie scaricate manualmente alla gestione automatica dei pacchetti con Nuget, posso dire che l'uso di un gestore pacchetti ha enormi vantaggi.

Il nostro prodotto è implementato in 27 progetti C #, che è relativamente piccolo per gli standard odierni. Alcune delle nostre dipendenze di terze parti hanno dozzine di assemblee.

Prima di Nuget, se avessi voluto aggiornare tutte le nostre dipendenze all'ultima versione avrei dovuto:

1. Rintraccia da dove ho potuto ottenere tutte le librerie aggiornate
2. Scaricali e decomprimi / installa
3. Aggiungi le nuove versioni al controllo del codice sorgente
4. Esaminare manualmente tutti i riferimenti nei nostri progetti e aggiornarli per indicare i nuovi assiemi

Con 27 progetti e dozzine di assemblee di dipendenze, questo processo era soggetto a errori e poteva richiedere ore.

Ora che ci siamo aggiornati all'utilizzo di Nuget, è tutto fatto per me con un solo comando.

Non è necessario alcuno strumento esterno per gestire i pacchetti

È una specie di non punto vero? Se uso un gestore di pacchetti, non ho bisogno di avere una cartella lib. Inoltre non devo gestire i pacchetti da solo.

Nessuna connessione Internet richiesta per costruire

A parte il fatto che non avere una connessione Internet oggi durante lo sviluppo è piuttosto raro (forse con l'eccezione di essere in transito), un gestore di pacchetti decente non dovrebbe richiedere di avere l'ultima versione per compilare la propria applicazione. Potrebbe lamentarsi, ma non c'è motivo di non compilare con la versione che ha già installato

Build più veloce (nessun controllo del pacchetto)

Questo è uno speedboost piuttosto marginale, ma puoi senza dubbio farne un punto.

Ambienti più semplici (meno conoscenza richiesta)

La maggior parte dei gestori di pacchetti è così semplice in questi giorni che non vale la pena provare a aggirarli facendo questi. Ci sono anche client visivi, se vuoi. In realtà nascondono molto del croft che sta succedendo.

I gestori pacchetti consentono anche di condividere questi pacchetti tra diversi progetti. Se 5 dei miei progetti utilizzano la stessa versione di Boost, non è necessario duplicarlo per ogni progetto. Ciò è particolarmente vero per i complessi alberi di dipendenza di cui parli.

Con una cartella lib gestisci i pacchetti solo per quel progetto, mentre un gestore pacchetti ti consente di farlo per l'intero ambiente di sviluppo con un unico strumento.

È la differenza tra il solo utilizzo delle librerie (directory lib) e il loro utilizzo, mantenendo le meta-informazioni (gestore pacchetti) . Tali meta-informazioni riguardano numeri di versione, dipendenze (transitive) tra librerie e simili.

Le discussioni sull'inferno delle DLL, sulla compatibilità delle librerie, sul sistema di moduli java, su OSGi e simili dovrebbero almeno essere sufficienti a convincere che vale la pena avere una qualche forma di gestione delle dipendenze.

• La versione della libreria e i problemi di dipendenza possono essere una perdita di tempo.

Inoltre c'è il vantaggio di un repository condiviso (locale), quindi molti progetti non hanno bisogno di conservare copie delle librerie importate. Se uno ha un progetto con 20 sottomoduli, alcuni di questi moduli hanno 40 dipendenze dispari.

• Più struttura
• Più rifinitura delle biblioteche
• Nessuna decisione umana ad hoc sulle biblioteche

Ci sono alcuni casi in cui potrebbe essere necessaria una cartella lib, ad esempio quando si tratta di librerie obsolete (una versione di essa non è più mantenuta / disponibile), una versione modificata localmente di una libreria, ...

Ma per tutto il resto, è come se lo sviluppatore assumesse il ruolo di gestore dei pacchetti:

• Lo sviluppatore dovrà scaricare le librerie (Internet richiesto)
• Lo sviluppatore dovrà verificare manualmente le versioni più recenti
• ...

E IMHO, sono necessarie meno conoscenze, perché è necessario conoscere l'utilizzo dello strumento esterno, ma meno sulle librerie (ovvero le dipendenze).

C'è un altro problema non coperto da altre domande: la condivisione dei deps.

Diciamo, hai due pacchetti che costruiscono la stessa libreria. Nel migliore dei casi, non ci saranno coflicts, ma lo stesso spazio HDD / SSD utilizzato due volte. Nel peggiore dei casi, ci saranno vari conflitti, come le versioni.

Se si utilizza Gestione pacchetti, installerà la libreria una sola volta (per versione) e fornirà già il percorso.

PS: ovviamente, hai bisogno di un collegamento dinamico (o di una funzione simile nella tua lingua) per ottenere questo professionista.

Uno dei motivi principali per cui le librerie condivise erano considerate un progresso nei sistemi Unix e Windows degli anni '90 era il modo in cui potevano ridurre l'utilizzo della RAM quando venivano caricati più programmi che utilizzavano lo stesso set di librerie. Lo spazio del codice deve essere allocato UNA VOLTA per ciascuna libreria e versione esatta di quella libreria , l'unico utilizzo della memoria per istanza rimanente è per le variabili statiche.

Molti sistemi operativi implementano librerie condivise in un modo che dipende da meccanismi come unix mmap () api - il che implica che una libreria non dovrà solo avere la stessa identica versione ma in realtà lo stesso FILE. Questo è semplicemente impossibile da sfruttare appieno per un programma che spedisce il proprio set di librerie.

Dato che la memoria è molto più economica e che le versioni delle librerie avevano bisogno di più varietà rispetto agli anni '90, questo argomento non ha molto peso oggi.