installando pacchetti python senza internet e usando il codice sorgente come .tar.gz e .whl

Question

stiamo provando ad installare un paio di pacchetti python senza internet.

For ex : python-keystoneclient 

Per questo abbiamo i pacchetti scaricati da https://pypi.python.org/pypi/python-keystoneclient/1.7.1 e lo ha tenuto in server.

Tuttavia, durante l'installazione dei pacchetti tar.gz e .whl, l'installazione sta cercando pacchetti dipendenti da installare prima. Dal momento che nel server non è presente alcuna connessione Internet, si sta verificando un errore.

Per es: python-keystoneclient abbiamo i seguenti pacchetti dipendenti

stevedore (>=1.5.0) 
six (>=1.9.0) 
requests (>=2.5.2) 
PrettyTable (<0.8,>=0.7) 
oslo.utils (>=2.0.0) 
oslo.serialization (>=1.4.0) 
oslo.i18n (>=1.5.0) 
oslo.config (>=2.3.0) 
netaddr (!=0.7.16,>=0.7.12) 
debtcollector (>=0.3.0) 
iso8601 (>=0.1.9) 
Babel (>=1.3) 
argparse 
pbr (<2.0,>=1.6) 

Quando provo a installare i pacchetti uno per uno dalla lista qui sopra, ancora una volta la sua ricerca di dipendenze nidificato.

C'è un modo per elencare ALL i pacchetti dipendenti per l'installazione di un modulo python come python-keystoneclient.

Answer 1

Questo è come mi occupo di questo caso:

Sulla macchina in cui ho accesso a Internet:

mkdir keystone-deps 
pip download python-keystoneclient -d "/home/aviuser/keystone-deps" 
tar cvfz keystone-deps.tgz keystone-deps 

quindi spostare il file tar alla macchina destinazione che non ha accesso a Internet ed effettua le seguenti operazioni:

tar xvfz keystone-deps.tgz 
cd keystone-deps 
pip install python_keystoneclient-2.3.1-py2.py3-none-any.whl -f ./ --no-index 

Answer 2

pipdeptree è un'utilità della riga di comando per la visualizzazione dei pacchetti python installati in un virtualenv sotto forma di un albero delle dipendenze. Basta usarlo: https://github.com/naiquevin/pipdeptree

Answer 3

Abbiamo una situazione simile al lavoro, dove le macchine di produzione non hanno accesso a Internet; quindi tutto deve essere gestito offline e off-host.

Ecco quello che ho provato con diverse quantità di successo:

1. basket che è una piccola utility che si esegue sul proprio host collegato a Internet. Invece di provare a installare un pacchetto, lo scaricherà, e tutto il resto che richiede di essere installato in una directory. Quindi si sposta questa directory sul computer di destinazione. Vantaggi: molto semplice e facile da usare, nessun mal di testa da server; nessuna porta da configurare. Contro: non ci sono veri showstoppers, ma il più grande è che non rispetta alcuna versione che si possa avere; scaricherà sempre l'ultima versione di un pacchetto.

2. Eseguire un server Pypi locale. Usato pypiserver e devpi. pypiserver è semplicissimo da installare e configurare; devpi richiede un po 'più di finishing. Entrambi fanno la stessa cosa: agiscono come proxy/cache per il vero pypi e come server pypi locale per tutti i pacchetti cresciuti in casa. localshop è una nuova che non c'era quando stavo guardando, ha anche la stessa idea. Quindi, come funziona, la tua macchina con accesso a Internet si collegherà a questi server, quindi saranno connessi a Internet in modo che possano memorizzare nella cache e proxy il repository effettivo.

Il problema con il secondo approccio è che, anche se si ottiene la massima compatibilità e l'accesso a tutta la repository di pacchetti Python, è ancora necessario per assicurarsi che qualsiasi/tutte le dipendenze sono installati sul computer di destinazione (ad esempio, qualsiasi intestazione per i driver del database e una toolchain di compilazione). Inoltre, queste soluzioni non soddisfano i repository non-pypi (ad esempio, i pacchetti che sono ospitati su github).

Siamo arrivati ​​molto lontano con la seconda opzione, quindi, lo consiglierei sicuramente.

Alla fine, stancati di dover gestire problemi di compatibilità e librerie, abbiamo migrato l'intero circo di server in container docker supportati commercialmente.

Ciò significa che spediamo tutto preconfigurato, non è necessario installare nulla sulle macchine di produzione e per noi è stata la soluzione più senza problemi.

Abbiamo sostituito i repository Pypi con un server di immagini docker locale.