mejor - python 3

¿Cuál es la forma correcta de trabajar con módulos compartidos en el desarrollo de Python?

Question

Estoy trabajando para adoptar Python como parte de la suite de herramientas de desarrollo de mi equipo. Con los otros lenguajes / herramientas que utilizamos, desarrollamos muchas funciones y clases reutilizables que son específicas del trabajo que hacemos. Esto estandariza la forma en que hacemos las cosas y ahorra una gran cantidad de reinvención de la rueda.

Parece que no puedo encontrar ningún ejemplo de cómo esto se maneja generalmente con Python. Ahora mismo tengo una carpeta de desarrollo en un disco local, con varias carpetas de proyectos debajo de eso, y una carpeta "común" adicional que contiene paquetes y módulos con clases y funciones reutilizables. Estos módulos "comunes" son importados por módulos dentro de múltiples proyectos.

Development/
Common/
Package_a/
Package_b/
Project1/
Package1_1/
Package1_2/
Project2/
Package2_1/
Package2_2/

Al tratar de aprender cómo distribuir una aplicación Python, parece que se supone que todos los paquetes a los que se hace referencia están debajo de la carpeta del proyecto de nivel superior, no como garantía. También se me ocurrió que tal vez el enfoque correcto es desarrollar módulos comunes / marco en un proyecto separado y, una vez probado, implementarlos en el entorno de cada desarrollador mediante la instalación en la carpeta de paquetes de sitio. Sin embargo, eso también plantea cuestiones de reparto.

¿Alguien puede aclarar esto o señalarme un recurso que discuta este problema?

Answer 1

... parece que se supone que todos los paquetes a los que se hace referencia están por debajo de la carpeta del proyecto de nivel superior, no como garantía.

Esto se debe principalmente a que el directorio de trabajo actual es la primera entrada en sys.path por defecto, lo que hace que sea muy conveniente importar módulos y paquetes debajo de ese directorio.

Si lo eliminas, ni siquiera puedes importar cosas del directorio de trabajo actual ...

$ touch foo.py
$ python
>>> import sys
>>> del sys.path[0]
>>> import foo
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named foo

También se me ocurrió que tal vez el enfoque correcto es desarrollar módulos comunes / marco en un proyecto separado y, una vez probado, implementarlos en el entorno de cada desarrollador mediante la instalación en la carpeta de paquetes de sitio.

No es realmente un problema importante para el desarrollo. Si está utilizando el control de versiones y todos los desarrolladores verifican el árbol de origen en la misma estructura, puede emplear fácilmente hacks de ruta relativa para asegurarse de que el código funciona correctamente sin tener que alterar las variables de entorno o los enlaces simbólicos.

Sin embargo, eso también plantea cuestiones de reparto.

Aquí es donde las cosas pueden complicarse un poco más, pero solo si planea lanzar bibliotecas independientemente de los proyectos que las usan y / o si varios instaladores de proyectos comparten las mismas bibliotecas. Si ese es el caso, eche un vistazo a distutils .

Si no es así, simplemente puede emplear las mismas rutas de acceso relativas que se usaron en el desarrollo para asegurarse de que proyecte trabajos "fuera de la caja".

Answer 2

Creo que esta es la mejor referencia para crear un paquete de Python distribuible:

Enlace eliminado, ya que conduce a un sitio pirateado.

Además, no crea que necesita anidar todo en un solo directorio. Puedes hacer cosas como

platform/
core/
coremodule
api/
apimodule

y luego hacer cosas como from platform.core import coremodule , etc.

Answer 3

La primera lectura obligatoria en este tipo de cosas está aquí:

¿Cuál es la mejor estructura de proyecto para una aplicación Python?

en caso de que no lo haya visto (y siga el enlace en la segunda respuesta).

La clave es que cada paquete principal sea importable como si "." era el directorio de nivel superior, lo que significa que también funcionará correctamente cuando se instale en un paquete de sitio. Lo que esto implica es que los paquetes principales deben ser planos dentro del directorio superior, como en:

myproject-0.1/
myproject/
framework/
packageA/
sub_package_in_A/
module.py
packageB/
...

Entonces, tanto usted (dentro de sus otros paquetes) como sus usuarios pueden importar como:

import myproject
import packageA.sub_package_in_A.module

etc

Lo que significa que debe pensar mucho sobre el comentario de @ MattAnderson, pero si desea que aparezca como un paquete distribuible por separado, debe estar en el directorio superior.

Tenga en cuenta que esto no impide que usted (o sus usuarios) hagan una:

import packageA.sub_package_in_A as sub_package_in_A

pero te impide permitir:

import sub_package_in_A

directamente.

Answer 4

Si tiene un código común que desea compartir en múltiples proyectos, puede valer la pena pensar en almacenar este código en un proyecto físicamente separado, que luego se importa como una dependencia en sus otros proyectos. Esto se logra fácilmente si aloja su proyecto de código común en github o bitbucket, donde puede usar pip para instalarlo en cualquier otro proyecto. Este enfoque no solo le ayuda a compartir fácilmente el código común en múltiples proyectos, sino que también lo protege de la creación involuntaria de dependencias erróneas (es decir, las que se dirigen desde su código común a su código no común).

El siguiente enlace proporciona una buena introducción al uso de pip y virtualenv para administrar las dependencias, definitivamente vale la pena leerlas si usted y su equipo son bastante nuevos en trabajar con python, ya que esta es una cadena de herramientas muy común que se usa para este tipo de problema:

http://dabapps.com/blog/introduction-to-pip-and-virtualenv-python/

Y el siguiente enlace le muestra cómo extraer las dependencias de github usando pip:

¿Cómo usar el software de instalación Python Pip para extraer paquetes de Github?