python - mac - Cómo incluir dependencias git en setup.py para instalar pip

pip install python 3

Question

Necesito incluir paquetes de Python disponibles a través de repositorios públicos de Github junto con mi paquete de Python (2.7). Mi paquete debe ser instalable a través de pip usando setup.py .

Hasta ahora, esto podría hacerse usando dependency_links en el archivo setup.py :

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"
   ]    
)

Esto aún funciona cuando el paquete se instala con el --process-dependency-links , pero la funcionalidad dependency_links parece estar en desuso, ya que:

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

me da la siguiente advertencia:

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

¿Hay alguna manera alternativa de incluir las dependencias de git en el archivo setup.py con soporte para la instalación de pip?

Editar (17/10/2016) para aclarar mi caso de uso:

Digamos que encuentro un error en other_package . Levanto el repositorio respectivo en Github, arreglo el error y hago una solicitud de extracción. Mi solicitud de extracción no se acepta de inmediato (o nunca lo será porque el paquete ya no se mantiene activamente). Me gustaría distribuir my_package junto con mi fork of other_package y quiero que los usuarios puedan instalar mi my_package sin ningún conocimiento adicional sobre los detalles de este requisito y sin tener que proporcionar ninguna bandera adicional en la instalación. Los usuarios de my_package deberían poder incluir my_package como requisito en sus propios paquetes personalizados.

¿Cómo se puede lograr teniendo compatibilidad con los diferentes modos de instalación (ruedas, huevos, desarrollo, ...) en mente?

Answer 1

Personalmente, evitaría incluir repositorios git como dependencias. En los escenarios que describes, veo dos opciones.

Donde el paquete no se mantiene

Si un paquete no se mantiene, puede bifurcar el proyecto y distribuir su propia versión, o puede distribuir el código bifurcado como un submódulo de su propio código (es decir, incluir la dependencia externa directamente en su paquete distribuible)

Personalmente prefiero distribuir mi propia versión.

Donde el paquete aún debe incluir su corrección de errores

En este caso, distribuiría el código fijo como parte de su paquete hasta el momento en que se solucione el error.