Uso de paquetes personalizados en mi proyecto python

Question

Estoy haciendo algunos proyectos en python en este momento, y estoy tratando de encontrar la manera de trabajar con mis propias versiones de paquetes de código abierto existentes.

Por ejemplo, estoy usando tipfy con zc.buildout, y lo he agregado en el paquete 'paypal'. Lamentablemente, no tiene una función que necesito, así que la he bifurcado en github y he agregado la función. Enviaré a los encargados de mantenimiento del paquete original una solicitud de extracción, pero tanto si aceptan mis adiciones como si no, me gustaría usar mi versión del paquete y mantener la comodidad de tener zc.buildout para administrar mis dependencias. ¿Cómo hago esto?

¿Debo cargar mi propia toma en la biblioteca a PyPI y prefijo con mi nombre? ¿No sería eso innecesariamente contaminar el índice?

¿O debería hacer y mantener mi propio repositorio de índices y paquetes? ¿Dónde encuentro el formato para esto? ¿Y es contrario a los términos de las licencias de OSS alojar mi propio repositorio con paquetes modificados con los mismos nombres? (Prefiero no modificar cada archivo en el proyecto con nuevos espacios de nombres)

Estoy seguro de que este problema aparece bastante, y no solo con Python. Puedo ver que esto también sucede con Maven y SBT ... ¿qué hace la gente cuando quiere usar sus propias versiones de paquetes populares?

Answer 1

Hay dos formas de hacerlo. Utilizo tanto, dependiendo del contexto, la buildout está siendo utilizado para:

1. Uso mr.developer para incluir paquetes de un sistema de control de versiones (mr.developer soportar una amplia gama de sistemas, incluyendo GIT). Lo uso cuando desarrollo.

2. Cree un repositorio de paquetes privado. Una simple lista de directorios en Apache es suficiente. Añadir la URL de su repositorio privado como una entrada find-links:

   [buildout] 
   ... 
   find-links = 
       ... 
       http://username:password@dist.example.com/projectname 
   

   En este ejemplo también incluí un nombre de usuario y contraseña (buildout continuación autenticará) y un camino en el servidor que es específico del proyecto. También puede crear un gran repositorio privado para todos sus proyectos, por supuesto.

   En ese repositorio pone huevos completos, o simplemente un tarball del paquete. Los repositorios nombrados en find-links se buscan antes de PyPI.

   Utilizo este método para las construcciones de despliegue. De esta forma, el software utilizará paquetes lanzados, lo que hace que la gestión de lanzamientos sea mucho más clara y simple.

alojamiento de su propio tenedores de paquetes de software libre está perfectamente bien! Esta es una de las libertades que obtienes cuando usas OSS. Tenga en cuenta que cuando organiza un código GPL como este y lo distribuye a un tercero, debe poner sus cambios a su disposición. Un repositorio de paquetes es una forma de cumplir con esto.

Answer 2

Se buscará primero cualquier ruta que ponga en dependency_links en setup.py de su proyecto. Así que simplemente deje caer su paquete en una ruta y configure dependency_links en esa ruta.

local_packages = ['file:///path/to/packages'] 

setup(
... 
dependency_links=local_packages, 
...) 

Setuptool documentos cubren un poco más sobre cómo funciona todo, pero eso es todo lo que hay que hacer.

Editar: zc.buildout usa setuptools dependency_links var de forma predeterminada. If you want to turn it off.

Answer 3

Para mantener su dolor de cabeza bajo control, realmente recomendaría agrupar todo ese código personalizado con su paquete. Digamos que hizo un tenedor de package. Mientras su licencia lo permita, solo empacaré la versión modificada de package con mi código, como si fuera solo otro directorio. Puede ubicarlo localmente en package para que sea fácil de encontrar. Una vez que los desarrolladores de package arreglen lo que necesita, solo elimine este directorio y vuelva a depender de un paquete en línea.

Una ventaja adicional de este enfoque es facilitar la distribución a usuarios/clientes.

Answer 4

Ha pasado un tiempo desde que utilicé buildout, pero si recuerdo correctamente, hay una receta de pip que le permite usar los archivos de requisitos de pip. Puede crear un archivo de requisitos que contenga algo como esto:

-e git+http://<github url> 

Eso comprobará el paquete localmente durante la instalación.

Answer 5

¿Debo cargar mi propia toma en la biblioteca a PyPI y prefijo con mi nombre?

Nº

no contaminaría que innecesariamente el índice?

Obviamente. (También, usted está asumiendo que su extensión es realmente útil a los demás. Puede que no sea tan útil a nadie más que a ti. De hecho, su extensión podría indicar una falta de comprensión del paquete.)

O debe ¿Realizo y mantengo mi propio repositorio de índices y paquetes?

Nunca. Eso es completamente tonto. Usted tiene el paquete modificado. No necesita un repositorio a menos que vaya a completarlo contra PyPI. Podrías intentarlo, pero ¿para qué molestarse?

---

Esto es lo que debes hacer.

extienden

Se puede extender fácilmente un paquete dado sin modificar o que se bifurcan.

my_paypal.py

from paypal import * 

class MyFancyExtension(SomeExistingClass): 
    def override(self, ...) 

def my_other_extension(...): 
    this() 
    that() 

Es bastante fácil. A menudo es mejor que bifurcar porque conserva el paquete original intacto por sus extensiones.

Answer 6

Tiene mucho sentido tener su propio servidor PyPI personalizado para sus paquetes propietarios, privados, bifurcados o de desarrollo. Por ejemplo, pypiserver es liviano y fácil de configurar.