Práctica recomendada para agrupar bibliotecas de terceros para su distribución en Python 3

Question

Estoy desarrollando una aplicación utilizando Python 3. ¿Cuál es la mejor práctica para usar bibliotecas de terceros para el proceso de desarrollo y la distribución del usuario final? Tenga en cuenta que estoy trabajando dentro de estas restricciones:

• Los desarrolladores en el equipo deben tener la misma versión exacta de las bibliotecas.
• Una solución ideal funcionaría tanto en Windows como en Linux.
• Me gustaría evitar hacer que el usuario instale el software antes de usar el nuestro; es decir, no deberían tener que instalar el producto A y el producto B antes de usar el nuestro.

Answer 1

No hay mejores prácticas, pero hay algunas pistas diferentes que las personas siguen. Con respecto a distribución producto comercial se encuentran los siguientes:

administrar su propio paquete de servidores

con respecto a su proceso de desarrollo, es típico que o bien tienen su actualización de cajas dev desde un servidor local de paquetes . Eso le permite "congelar" la lista de dependencias (es decir, simplemente dejar de recibir actualizaciones de flujo ascendente) para que todos estén en la misma versión. Puede actualizar en determinados momentos y hacer que los desarrolladores también se actualicen, manteniendo a todos al mismo paso.

Para las instalaciones del cliente, generalmente se escribe una secuencia de comandos de instalación. Puede recopilar todos los paquetes e instalar sus libs, al igual que el otro al mismo tiempo. Puede haber problemas al intentar instalar un nuevo Python, o incluso cualquier biblioteca estándar porque el cliente ya puede depender de una versión diferente. Por lo general, puede instalarlo en una caja de arena para separar sus paquetes de los paquetes del sistema. Esto es más un problema en Linux que en Windows.

Toolchain

La otra opción es crear un conjunto de herramientas para cada sistema operativo soportado. Una cadena de herramientas es todas las dependencias (hasta, pero sin incluir las librerías básicas del sistema operativo como glibc).Esta cadena de herramientas se empaqueta y se distribuye para los clientes de los desarrolladores y. La mejor práctica para una cadena de herramientas es:

• cambiar el ejecutable para evitar confusiones. (es decir, python -> pkg_python)
• no instalar en los directorios .../bin para evitar el uso accidental. (es decir, en Linux puede instalar bajo .../libexec. /opt también se usa aunque personalmente lo detesto.)
• instale sus libs en la ubicación correcta bajo lib/python/site-packages para que no tenga que usar PYTHONPATH.
• Distribuya los archivos de origen .py para los ejecutables, de modo que el script de instalación pueda ubicarlos de manera adecuada.
• formato El paquete debe ser un paquete nativo OS (RedHat -> RPM, Debian -> DEB, Win -> MSI)

Answer 2

Suponiendo que las bibliotecas 3 ª parte están disponibles en PyPI, utilice distutils, y especificar las versiones requeridas en setup.py.

Answer 3

• Para desarrolladores use PIP con requirements file.
• Para usuarios finales, especifique requisitos en setup.py.

Answer 4

Puede usar setuptools para crear archivos de huevos para sus bibliotecas, suponiendo que ya no estén disponibles en forma de huevo. A continuación, podría agrupar los huevos junto con su software, que necesitaría instalarlos o asegurarse de que estaban en la ruta de importación.

Esto tiene algunas complejidades, es decir, si sus bibliotecas tienen C-extensions, entonces sus huevos se vuelven específicos de la plataforma, pero en mi experiencia este es el medio más ampliamente aceptado de 'agrupar' cosas en Python.

Tengo que decir que esto sigue siendo una de las debilidades de Python; el ecosistema de terceros ciertamente está dirigido a los desarrolladores en lugar de a los usuarios finales.