Perché le librerie vengono spedite separatamente anziché in bundle con ogni programma?


10

So perché questo è buono in generale: correzioni di sicurezza più veloci, packaging più semplice, più funzionalità. Tuttavia, sto cercando di convincere alcuni colleghi che non abbiamo bisogno di raggruppare una biblioteca con il nostro programma. Non funzionerà senza questa biblioteca, ma la biblioteca è rimasta stabile per un po 'di tempo e rimarrà tale per il prossimo futuro. Non vedo alcun motivo per NON separarlo.

Quali argomenti potrei usare per convincerli?


La mia situazione specifica è questa: sto lavorando su SymPy , che è una libreria Python open source per la matematica simbolica. Una parte fondamentale di esso è mpmath , che è una libreria per l'aritmetica in virgola mobile multi-previsione. SymPy non funziona senza mpmath, non c'è alternativa. Come tale, è stato fornito in bundle con SymPy sin dall'inizio (mi è stato detto che di solito c'erano piccole incompatibilità da risolvere ogni volta che una nuova versione veniva importata). Va anche notato che lo sviluppatore di mpmath era coinvolto nello sviluppo di SymPy. Ora c'è un problema su unbundling mpmath, puoi leggere tutto qui .

Per riassumere la discussione lì:

Unbundle:

  • Porting un po 'più semplice su Python 3 (argomento secondario IMHO)

  • Imballaggio più semplice per le distribuzioni

  • Aggiornamenti più rapidi (di sicurezza) agli utenti

  • "L'imballaggio e la gestione delle dipendenze sono problemi difficili, ma sono risolti. Questo non è sicuramente un settore in cui dovremmo fare le nostre cose."

Continua a raggruppare:

  • Installazione. È facile su Linux, più difficile su Mac e molto difficile su Windows. Mancanza di accesso limitato e altri problemi.

  • è parte integrante di SymPy, ovvero sympy non funziona senza di essa (affatto)

  • non esiste nessun altro pacchetto che possa fare il lavoro di mpmath

  • "Quando, come utente, scarico sympy, mi aspetto che funzioni."


Questa è la mia situazione specifica, ma accetterei una risposta che fornisca anche una buona risposta generale.


È necessario fornire maggiori informazioni sulla situazione specifica per ottenere una risposta migliore. Ad esempio, quale ambiente stai pianificando di eseguirlo? Sarà esposto a Internet?
Tshepang,

La tua applicazione è open source?
Anton Barkovsky,

@Anton Sì, è SymPy , una libreria Python open source per la matematica simbolica. Ci sto lavorando come studente GSoC (divulgazione completa :)).
VPeric,

@Tshepang La discussione è disponibile all'indirizzo: code.google.com/p/sympy/issues/detail?id=2482
VPeric,

@VPeric: Sarebbe molto bello riassumere quella discussione, solo per risparmiare tempo per coloro che sono disposti a rispondere alla tua domanda.
Tshepang,

Risposte:


5

Ancora un'altra risposta, ma una che considero la più importante (solo la mia opinione personale), sebbene anche le altre siano tutte buone risposte.

Il packaging della lib separatamente consente di aggiornare la lib senza la necessità di aggiornare l'applicazione. Dì che c'è un bug nella libreria, invece di essere in grado di aggiornare la libreria, dovresti aggiornare l'intera applicazione. Ciò significa che la tua applicazione avrebbe bisogno di un bump della versione senza che il suo codice fosse cambiato, proprio a causa della lib.


1
Questo è un punto importante ed è parte del motivo per cui a molte distribuzioni non piace avere librerie in bundle con i programmi; per esempio Debian ha una politica di non raggruppare una libreria con un eseguibile o di collegare staticamente una libreria a meno che non possa mai essere usata solo da quel particolare programma (o, per il collegamento statico, quei casi in cui il collegamento dinamico non è supportato).
Gilles 'SO- smetti di essere malvagio' il

Alla fine, questo è forse il punto più importante. Concordo anche con le altre risposte, ma ho dovuto sceglierne solo una. :)
VPeric,

6

Oltre ai vantaggi che hai citato (sicurezza, packaging, funzionalità), posso pensare ad alcuni altri:

  • Qualcuno che troverebbe la funzionalità utile per un altro programma non avrebbe bisogno di fare il lavoro di separarlo. Cioè se sa anche se la funzionalità esiste nel tuo progetto sotto forma di libreria in primo luogo. Questo dipende da quanto bene è progettato ... se il tuo progetto è abbastanza modulare.

  • Nel caso in cui ciò fosse utile per altri progetti, ciò ridurrebbe le dimensioni dell'utilizzo del disco in generale (ad es. Solo una copia del codice).

  • Ciò migliorerebbe la qualità del tuo codice, costringendoti a eseguire alcuni (tanto necessari) refactoring. Come nel primo punto sopra, anche questo dipende dalla qualità del tuo codice.

  • Aumentare il numero di utenti della libreria (se viene diviso) contribuirebbe a renderlo più generico, il che probabilmente migliorerà anche la sua qualità.


1
Tutti i punti positivi. Suppongo che potrebbe essere letto come "a prova di futuro": alcuni dei tuoi punti si applicano attualmente (al momento mpmath è utilizzato solo in un paio di altri progetti), ma è facile vedere che ciascuno dei tuoi punti guadagna valore per ogni nuovo progetto usando mpmath.
VPeric,

4

Mentre i vantaggi sono evidenti, la facilità di distribuzione sembra essere l'argomento principale per la spedizione della libreria insieme al programma nel tuo caso.

Ecco alcuni altri argomenti contro il raggruppamento:

  • In Linux, è compito del manutentore della distribuzione garantire che la tua biblioteca funzioni bene con le sue dipendenze. La maggior parte degli utenti scaricherà comunque la libreria utilizzando il gestore dei pacchetti della distribuzione. Coloro che usano il trunk di solito non si preoccuperanno comunque di dedicare tempo alla configurazione della libreria.

  • In Windows e Mac OS, i gestori di pacchetti Python come pip sono di solito utilizzati comunque, poiché l'installazione manuale delle librerie è complicata.

  • Ci sono state persino discussioni sulla distribuzione forzata nel motore di app di Google, ma non tutti i web framework sono eseguiti su di esso. Molti richiedono persino il porting, lo spazio su disco per le librerie è limitato e dopo tutto è l'hosting di applicazioni Web! È improbabile che l'applicazione Web utilizzi matematica simbolica.

  • Nessuno ti impedisce di visualizzare messaggi di errore puliti se la dipendenza non è disponibile o ha una versione errata.

  • Le persone spesso lo odiano quando il programma si considera più intelligente di loro. Consenti agli utenti di prendersi cura del proprio sistema.


Puoi spiegare l'ultimo punto. Non so dire se sia un argomento a favore / contro il raggruppamento.
Tshepang,

3
Lo capisco come contro il raggruppamento: gli utenti vogliono installare ciò che vogliono, non farmi imporre una versione particolare su di essi.
VPeric,

3

Il modo corretto di gestire la disaggregazione in un pacchetto di installazione di Windows sarebbe quello di avere il test preesistente per l'esistenza della libreria e se non è presente offrire di installarlo dal pacchetto di libreria che si include nel pacchetto di installazione del software. Sono abbastanza sicuro che la maggior parte delle app GTK con porte Windows facciano qualcosa del genere - lo so pidgin .


3

Una taglia non deve adattarsi a tutti.

Per le distribuzioni di origine, se si raggruppano, i pacchetti su molte distribuzioni (almeno delle eredità di Debian e Fedora) dovranno fare un lavoro aggiuntivo per disabilitare o rimuovere il raggruppamento, poiché le politiche di pacchetto per tali piattaforme vietano o almeno scoraggiano fortemente il raggruppamento. Pertanto, raggruppando si crea più lavoro per il downstream con pochissimi benefici. Questa discussione potrebbe avere qualche peso?

Le distribuzioni binarie (se fornite) potrebbero andare in entrambi i modi; il raggruppamento probabilmente ha senso per quelli, poiché non sono utilizzati da downstream.

Ma non c'è motivo per cui non puoi prendere la decisione e il pacchetto opposti per gli installatori di Windows e Mac.


1
Sebbene io sia d'accordo in generale, crea un onere aggiuntivo (per quanto piccolo), il che significa che probabilmente nessuno appoggerebbe questa soluzione.
VPeric,

2

Il raggruppamento vs. la dipendenza è un vecchio dibattito nel mondo del packaging. Questo documento racconta queste due scuole di pensiero: http://www.aosabook.org/en/packaging.html


2
Questa è stata una lettura interessante, ma parla più dei dettagli di implementazione e delle varie specifiche di Python che della filosofia generale.
VPeric,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.