Wie git Abhängigkeiten in setup.py für Pip-Installation enthalten

Question

Ich muss Python-Pakete über öffentliche Github-Repositorys zusammen mit meinem Python (2.7) -Paket enthalten. Mein Paket sollte über pip unter Verwendung von setup.py installierbar sein.

Bisher werden könnte dies mit dependency_links in der setup.py Datei getan:

setuptools.setup(
    name="my_package", 
    version="1.0", 
    install_requires=[ 
     "other_package==1.2" 
    ], 
    dependency_links=[ 
     "https://github.com/user/other_package/tarball/master#egg=other_package-1.2" 
    ]  
) 

Dies funktioniert nach wie vor, wenn das Paket mit der --process-dependency-links Flagge installiert wird, aber die dependency_links Funktionalität scheint veraltet zu sein, da:

pip install git+https://github.com/user/my_package@master#egg=my_package-1.0 --process-dependency-links 

gibt mir die folgende Warnung:

DEPRECATION: Dependency Links processing has been deprecated and will be removed in a future release. 

Gibt es eine alternative Möglichkeit, git Abhängigkeiten in die Datei setup.py mit Unterstützung für Pip-Installation aufzunehmen?

Edit (2016.10.17) mein Anwendungsfall zu klären:

Lassen Sie uns sagen, dass ich einen Fehler in other_package finden. Ich gabel das entsprechende Repo auf Github, behebe den Bug und mache eine Pull-Anfrage. Meine Pull-Anfrage wird nicht sofort akzeptiert (oder wird nie sein, weil das Paket nicht mehr aktiv gepflegt wird). Ich möchte my_package gemeinsam mit meinem Fork other_package verteilen und möchten, dass Benutzer my_package pip installieren können ohne weitere Kenntnisse über die Details dieser Anforderung und ohne zusätzliche Flags bei der Installation bereitzustellen. Benutzer von my_package sollten außerdem in der Lage sein, my_package als eine Anforderung in ihren eigenen benutzerdefinierten Paketen aufzunehmen.

Wie kann dies erreicht werden, kompatibel mit verschiedenen Arten der Installation (Räder, Eier, entwickeln, ...) im Auge?

Answer 1

Persönlich würde ich vermeiden, git-Repositorys als Abhängigkeiten einzuschließen. In den Szenarien, die Sie beschreiben, sehe ich zwei Optionen.

Wo Nicht gepflegtes Paket

ist Wenn ein Paket nicht betreut ist, können Sie entweder das Projekt gabeln und Ihre eigene Version verteilen, oder Sie können als als Submodul von Ihrem eigenen Code (dh umfasst den gegabelten Code verteilen die externe Abhängigkeit direkt in Ihrem verteilbaren Paket)

Persönlich bevorzuge ich, meine eigene Version zu verteilen.

Wo das Paket noch Ihre Bugfix

In diesem Fall beinhalten muss, würde ich den festen Code als Teil des Pakets, bis eine solche Zeit verteilen, wie der Fehler behoben ist.