python 3.x - for - La mejor práctica para agrupar bibliotecas de terceros para su distribución en Python 3

python distribute

Question

Estoy desarrollando una aplicación usando 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 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

Puede usar las herramientas de configuración para crear archivos de huevo 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 extensiones C, sus huellas se vuelven específicas de la plataforma, pero en mi experiencia, este es el medio más ampliamente aceptado de ''agrupar'' cosas en Python.

Debo 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.

Answer 2

Suponiendo que las bibliotecas de terceros están disponibles desde pypi, use distutils y especifique las versiones requeridas en setup.py.

Answer 3

• Para los desarrolladores, use PIP con el archivo de requisitos .
• Para los usuarios finales, especifique los requisitos en setup.py .

Answer 4

No hay mejores prácticas, pero hay algunas pistas diferentes que las personas siguen. Con respecto a la distribución de productos comerciales , hay los siguientes:

Administre su propio servidor de paquetes

Con respecto a su proceso de desarrollo, es típico tener su actualización de cajas de desarrollo desde un servidor de paquetes local. Eso le permite "congelar" la lista de dependencias (es decir, simplemente deje 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 una cadena de herramientas para cada sistema operativo compatible. Una cadena de herramientas son todas las dependencias (hasta, pero sin incluir las librerías básicas del sistema operativo como glibc ). Esta cadena de herramientas se empaqueta y distribuye tanto para desarrolladores como para clientes. La mejor práctica para una cadena de herramientas es:

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