I pacchetti Python sono spesso ospitati in molti repository di distribuzione. Dopo aver letto questo tutorial, in particolare la sezione intitolata "Vuoi davvero farlo", ho evitato di usare pip e ho preferito usare il repository di sistema, ricorrendo a pip solo quando ho bisogno di installare un pacchetto non nel repository.

Tuttavia, poiché si tratta di un metodo di installazione incoerente, sarebbe meglio usare solo pip? Quali sono i vantaggi / i detrattori dell'uso di pip sul repository del sistema per i pacchetti disponibili in entrambi i posti?

Il link che ho incluso afferma

Il vantaggio di utilizzare sempre i pacchetti Debian / NeuroDebian standard è che i pacchetti sono accuratamente testati per essere compatibili tra loro. I pacchetti Debian registrano dipendenze con altre librerie in modo da ottenere sempre le librerie necessarie come parte dell'installazione.

Io uso l'arch. È questo il caso di altri sistemi di gestione dei pacchetti oltre a apt?

Il più grande svantaggio che vedo nell'uso pipdell'installazione di moduli Python sul tuo sistema, sia come moduli di sistema che come moduli utente, è che il sistema di gestione dei pacchetti della tua distribuzione non ne sarà a conoscenza. Ciò significa che non verranno utilizzati per nessun altro pacchetto che ne abbia bisogno e che potresti voler installare in futuro (o che potrebbe iniziare a utilizzare uno di quei moduli a seguito di un aggiornamento); ti ritroverai quindi con entrambe le pipversioni dei moduli gestite dalla distribuzione, il che può causare problemi ( di recente mi sono imbattuto in un'altra istanza di questo ). Quindi la tua domanda finisce per essere una proposta del tutto o niente: se solo usipip per i moduli Python, non è più possibile utilizzare il gestore pacchetti della distribuzione per tutto ciò che desidera utilizzare un modulo Python ...

Il consiglio generale dato nella pagina a cui ti sei collegato è molto buono: prova ad usare i pacchetti della tua distribuzione il più possibile, usa solo pipper moduli che non sono impacchettati, e quando lo fai, fallo nella tua configurazione utente e non nel sistema- largo. Utilizzare gli ambienti virtuali per quanto possibile, in particolare per lo sviluppo dei moduli. Soprattutto su Arch, non dovresti imbatterti in problemi causati da moduli più vecchi; anche nelle distribuzioni in cui ciò può rappresentare un problema, gli ambienti virtuali lo affrontano abbastanza rapidamente.

Vale sempre la pena considerare che i pacchetti di librerie e moduli di una distribuzione sono impacchettati principalmente per l'uso di altri pacchetti nella distribuzione; averli in giro è un buon effetto collaterale per lo sviluppo usando quelle librerie e moduli, ma non è il caso d'uso principale.

TL; DR

• usa pip(+ virtualenv) per cose (libs, framework, forse strumenti di sviluppo) che i tuoi progetti (che sviluppi) usano
• usa il gestore pacchetti per le applicazioni che usi (come utente finale)

Dipendenze dallo sviluppo

Se stai sviluppando software in Python, ti consigliamo di utilizzarlo pipper tutte le dipendenze del progetto, che si tratti di dipendenze di runtime, dipendenze in fase di compilazione o elementi necessari per i test automatizzati e i controlli di conformità automatizzati (linter, controllo di stile, controllo di tipo statico ...)

Ci sono diverse ragioni per questo:

• Ciò ti consente di utilizzare virtualenv (direttamente o tramite virtualenvwrapper o pipenv o altri mezzi) per separare le dipendenze di diversi progetti l'uno dall'altro e isolare le applicazioni Python che utilizzi "in produzione" (come utente) da qualsiasi shenanigans esotico (o anche solo incompatibilità) che possono andare avanti nello sviluppo.
• Ciò consente di tenere traccia di tutte le dipendenze di un progetto in un file requirements.txt(se il progetto è un'applicazione) o setup.py(se il progetto è una libreria o un framework). Questo può essere verificato nel controllo di revisione (ad esempio Git) insieme al codice sorgente, in modo da sapere sempre quale versione del codice si basava su quali versioni delle dipendenze.
• Quanto sopra consente ad altri sviluppatori di collaborare al tuo progetto anche se non usano la stessa distribuzione Linux o nemmeno lo stesso sistema operativo (se le dipendenze utilizzate sono disponibili anche su Mac e Windows o qualsiasi altra cosa che usino, cioè)
• Non vuoi che gli aggiornamenti automatici del gestore pacchetti del tuo sistema operativo rompano il tuo codice. Dovresti aggiornare le tue dipendenze, ma dovresti farlo consapevolmente e a volte scegli, in modo da poter essere pronto a correggere il codice o ripristinare l'aggiornamento. (Il che è semplice se si tiene traccia della dichiarazione di dipendenza completa nel proprio sistema di controllo delle revisioni, insieme al proprio codice.)

Se ritieni di dover separare le dipendenze dirette e indirette (o distinguere tra un intervallo di versioni accettabile per una dipendenza e una versione effettiva utilizzata, vedi "pinning della versione") cerca pip-tools e / o pipenv. Ciò consentirà inoltre di distinguere tra dipendenze di build e test. (Probabilmente è possibile codificare la distinzione tra dipendenze build e runtime setup.py)

Le applicazioni che usi

Per le cose che usi come normale applicazione e che sembra essere scritto in Python, preferisci il gestore dei pacchetti del tuo sistema operativo. Si assicurerà che rimanga ragionevolmente aggiornato e compatibile con altre cose installate dal gestore dei pacchetti. La maggior parte delle distribuzioni Linux affermerà inoltre di non distribuire malware.

Se qualcosa di cui hai bisogno non è disponibile nel repository di pacchetti predefinito della tua distribuzione, puoi consultare repository di pacchetti aggiuntivi (ad es. Launchpad di distribuzioni basate su deb) o utilizzare pipcomunque. In quest'ultimo caso, utilizzare --userper l'installazione a casa dell'utente anziché a livello di sistema, in modo da avere meno probabilità di interrompere l'installazione di Python. (Per cose che ti servono solo temporaneamente o raramente, puoi persino usare un virtualenv.)

Un altro motivo per andare con il gestore pacchetti è che gli aggiornamenti verranno applicati automaticamente, il che è fondamentale per la sicurezza. Pensa se il pacchetto di bean utilizzato da Equifax fosse stato aggiornato automaticamente tramite yum-cron-security, l'hack potrebbe non essersi verificato.

Nella mia casella di sviluppo personale utilizzo Pip, in quanto utilizzo pacchetti.

Se stiamo parlando dell'installazione di pacchetti python da usare nel codice che stai scrivendo, usa pip.

Per ogni progetto a cui stai lavorando, crea un ambiente virtuale, quindi usa pip solo per installare le cose di cui ha bisogno quel progetto. In questo modo, installi tutte le librerie che utilizzi in modo coerente e sono contenute e non interferiscono con tutto ciò che installi tramite il tuo gestore pacchetti.

Se stai pianificando di rilasciare qualsiasi codice Python, in genere, aggiungi un setup.pyo requirements.txtal tuo progetto, che consentirà a pip di ottenere automaticamente tutte le sue dipendenze. Consente di creare o ricreare facilmente un ambiente virtuale per quel progetto.

Sommario

Esistono tre categorie generali di moduli con cui hai a che fare:

1. Quei programmi di supporto installati per tutti gli utenti con il sistema di pacchetti del sistema operativo. (Ciò può anche includere strumenti e librerie utilizzate dalle persone che programmano in Python; vedere di seguito.) Per questi usi i pacchetti del sistema operativo dove puoi e pipinstalla nelle directory di sistema dove necessario.
2. Quei programmi di supporto installati da un determinato utente solo per uso personale, e anche per alcuni aspetti del suo uso quotidiano di Python come linguaggio di scripting. Per questi usa pip --user, forse pyenv o pythonz , e strumenti e tattiche simili.
3. Coloro che supportano lo sviluppo e l'uso di un'applicazione specifica. Per questi usi virtualenv(o uno strumento simile).

Ogni livello qui può anche ottenere supporto da un livello precedente. Ad esempio, il nostro utente in (2) potrebbe fare affidamento su un interprete Python installato tramite pacchetti del sistema operativo.

Andando in questo in un po 'più in dettaglio:

Programmi e pacchetti di sistema

I programmi scritti in Python che si desidera "eseguire" sono facili: basta usare gli strumenti di installazione del sistema operativo e lasciare che portino tutto ciò di cui hanno bisogno; questo non è diverso da un programma non Python. Questo probabilmente porterà strumenti / librerie Python (come lo stesso interprete Python!) Su cui gli utenti della tua macchina potrebbero iniziare a fare affidamento; questo non è un problema purché comprendano la dipendenza e, idealmente, conoscano mezzi alternativi per gestirlo su host che non forniscono tali dipendenze.

Un esempio comune e semplice di tale dipendenza sono alcuni dei miei script personali ~/.local/bin/che iniziano con #!/usr/bin/env python. Funzioneranno bene (purché funzionino con Python 2) su RH / CentOS 7 e la maggior parte (ma non tutte) le installazioni di Ubuntu; non verranno installati su un'installazione Debian di base o su Windows. Per quanto non mi piaccia il mio ambiente personale che ha molto in termini di dipendenze dai pacchetti di sistemi operativi (lavoro su un numero di sistemi operativi diversi), qualcosa del genere trovo abbastanza accettabile; il mio piano di backup sui rari host che non dispongono di un sistema Python e non riescono a ottenerlo è di utilizzare un sistema utente come descritto di seguito.

Anche le persone che usano un interprete Python di sistema dipendono solitamente dal sistema pip3. Ecco dove di solito traccio la linea sulle dipendenze del mio sistema; tutto da virtualenvavanti mi occupo di me stesso. (Ad esempio, il mio script di attivazione standard si basa su qualunque cosa si trovi pip3o pipsi trovi nel percorso, ma scarica la propria copia di virtualenvbootstrap dell'ambiente virtuale che sta creando.

Detto questo, ci sono probabilmente circostanze in cui è perfettamente ragionevole rendere più disponibile un ambiente di sviluppo. Potresti avere interfacce Python in pacchetti complessi (come un DBMS) in cui vuoi usare la versione di sistema di quello e pensi che sia meglio lasciare che il sistema scelga anche il particolare codice della libreria Python che userai per parlarci. Oppure potresti distribuire molti host con un ambiente di sviluppo di base per una classe Python e trovare l'automazione più semplice con i pacchetti di sistema standard.

Programmi e pacchetti "giornalieri" dell'utente

Gli utenti possono avere librerie o programmi Python che non si adattano bene in un ambiente virtuale perché vogliono innanzitutto aiutare a creare ambienti virtuali (ad esempio, virtualenvwrapper ) o sono cose che usi comunemente dalla riga di comando anche mentre facendo un lavoro non Python. Anche se hanno la capacità di installare versioni di sistema di questi, potrebbero sentirsi più a loro agio nell'installare le proprie (ad es. Perché vogliono usare l'ultima versione dello strumento e le sue dipendenze).

Generalmente pip --userè ciò che le persone useranno per questo, anche se alcune dipendenze, come lo stesso interprete Python, richiedono un po 'di più. pyenv e pythonz sono utili per costruire interpreti personali (sia che siano installati ~/.local/bincome interprete predefinito o meno), e ovviamente si può sempre semplicemente costruire "a mano" dalla fonte se le librerie di sviluppo sono disponibili.

Cerco di mantenere il minimo set di cose installato qui: virtualenvwrapper (perché lo uso costantemente) e forse l'ultima versione di pip. Cerco di evitare dipendenze al di fuori della libreria standard o su Python 3 per gli script personali che scrivo per essere utilizzati su molti host. (Anche se vedremo per quanto tempo riuscirò a resistere mentre sposterò sempre più questi script personali su Python.)

Sviluppo separato di applicazioni e ambienti di runtime

Questa è la solita cosa di virtualenv. Per lo sviluppo dovresti quasi sempre usare un virtualenv per assicurarti di non usare dipendenze di sistema, o spesso più di uno per testare su diverse versioni di Python.

Questi ambienti virtuali sono utili anche per le applicazioni con molte dipendenze in cui si desidera evitare di inquinare l'ambiente dell'utente. Ad esempio, di solito installo un virtualenv per l'esecuzione di notebook Jupyter e simili.