Installation von Python-Paketen ohne Internet und Verwendung von Quellcode als .tar.gz und .whl

Question

Wir versuchen, einige Python-Pakete ohne Internet zu installieren.

For ex : python-keystoneclient 

Dafür haben wir die von https://pypi.python.org/pypi/python-keystoneclient/1.7.1 heruntergeladenen Pakete und hielt es in Server.

Während der Installation von tar.gz- und .whl-Paketen sucht die Installation jedoch nach abhängigen Paketen, die zuerst installiert werden sollen. Da auf dem Server keine Internetverbindung besteht, wird es fehlgeschlagen.

Für Ex: Für Python-keystoneclient haben wir die folgenden abhängigen Pakete

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) 

Wenn ich versuche, Pakete eins nach dem anderen aus der obigen Liste zu installieren, erneut seine für verschachtelte Abhängigkeit suchen.

Gibt es eine Möglichkeit, können wir ALL die abhängigen Pakete für die Installation eines Python-Moduls wie Python-Keystoneclient auflisten.

Answer 1

Dies ist, wie ich diesen Fall behandeln:

Auf der Maschine, wo ich Zugang zu Internet haben:

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

Dann die TAR-Datei auf die Zielmaschine bewegen, dass hat keinen Internetzugang und führt folgendes aus:

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 ist ein Befehlszeilendienstprogramm zum Anzeigen der in einem virtualenv installierten Python-Pakete in Form einer Abhängigkeitsstruktur. es einfach verwenden: https://github.com/naiquevin/pipdeptree

Answer 3

Wir haben eine ähnliche Situation bei der Arbeit, wo die Produktionsmaschinen keinen Zugang zum Internet haben; Daher muss alles offline und extern verwaltet werden.

Hier ist, was ich mit verschiedenen Mengen von Erfolg versucht:

1. basket, die ein kleines Programm, das Sie auf Ihrem Internet verbundenen Host ausgeführt werden. Anstatt zu versuchen, ein Paket zu installieren, wird es stattdessen heruntergeladen und alles, was es sonst noch benötigt, um in ein Verzeichnis installiert zu werden. Sie verschieben dieses Verzeichnis dann auf Ihren Zielrechner. Vorteile: sehr einfach und einfach zu bedienen, keine Server Kopfschmerzen; Keine zu konfigurierenden Ports. Nachteile: Es gibt keine wirklichen Showstopper, aber die größte ist, dass es keine Versionsfixierung respektiert, die Sie haben könnten; Es wird immer die neueste Version eines Pakets herunterladen.

2. Führen Sie einen lokalen Pypi-Server aus. Verwendet pypiserver und devpi. pypiserver ist super einfach zu installieren und einzurichten; devpi dauert ein bisschen mehr Finling. Beide machen das gleiche - agieren als Proxy/Cache für den echten Pypi und als lokaler Pypi-Server für selbst erstellte Pakete. localshop ist eine neue, die nicht da war, als ich suchte, es hat auch die gleiche Idee. So, wie es funktioniert, wird Ihre Internet-beschränkte Maschine eine Verbindung zu diesen Servern herstellen, sie werden dann mit dem Internet verbunden, so dass sie das tatsächliche Repository zwischenspeichern und proxy können.

Das Problem mit dem zweiten Ansatz ist, dass Sie zwar eine maximale Kompatibilität und Zugriff auf das gesamte Repository von Python-Pakete zu bekommen, müssen Sie noch sicherstellen, dass jede/alle Abhängigkeiten auf dem Zielcomputer installiert sind (zB beliebige Header für Datenbanktreiber und eine Build-Toolchain). Außerdem sind diese Lösungen nicht für Nicht-Pypi-Repositorys geeignet (z. B. Pakete, die auf GitHub gehostet werden).

Wir waren sehr weit mit der zweiten Option, also würde ich es auf jeden Fall empfehlen.

Nachdem wir es satt hatten, mit Kompatibilitätsproblemen und Bibliotheken fertig zu werden, migrierten wir den gesamten Server-Zirkus auf kommerziell unterstützte Docker-Container.

Dies bedeutet, dass wir alles vorkonfiguriert liefern, nichts muss auf den Produktionsmaschinen installiert werden und es war die am meisten kopfwehfreie Lösung für uns.

Wir ersetzten die Pypi-Repositorys durch einen lokalen Docker-Image-Server.