Python “setup.py develop”: ¿es posible crear una carpeta “.egg-info” que no esté en la carpeta de código fuente?

Python tiene la capacidad de “pseudoinstalar” un paquete ejecutando su script setup.py con develop lugar de install . Esto modifica el entorno de Python para que el paquete pueda importarse desde su ubicación actual (no se copia en el directorio de site-package ). Esto permite desarrollar paquetes que son utilizados por otros paquetes: el código fuente se modifica en su lugar y los cambios están disponibles para el rest del código de Python a través de una import simple.

Todo funciona bien, excepto que el comando setup.py develop crea una carpeta .egg-info con metadatos al mismo nivel que setup.py . La combinación de código fuente y archivos temporales no es una buena idea: esta carpeta debe agregarse a las listas de “ignorar” de múltiples herramientas a partir de vcs y sistemas de copia de seguridad.

¿Es posible usar setup.py develop pero crear el directorio .egg-info en algún otro lugar, para que el código fuente original no esté contaminado por el directorio y los archivos temporales?

setup.py develop crea un huevo de python, en el lugar; no [modifica el] entorno de Python, por lo que el paquete se puede importar desde su ubicación actual . Aún tiene que agregar su ubicación a la ruta de búsqueda de python o usar el directorio en el que se encuentra como el directorio actual.

Es tarea del comando develop crear un huevo en el lugar, que puede incluir comstackr extensiones C, ejecutar el proceso de conversión de 2 a 3 en Python para crear un código compatible con Python3, y proporcionar metadatos en los que se pueda confiar otro código Python. Cuando instala el paquete como un huevo en su directorio de site-packages , los mismos metadatos también se incluyen allí. Los datos no son temporales (se extraen de su archivo setup.py para que otras herramientas los setup.py analizar fácilmente).

La intención es que luego pueda confiar en esos metadatos cuando use su paquete en un sistema más amplio que se base en la presencia de los metadatos, mientras sigue desarrollando el paquete. Por ejemplo, en una implementación de desarrollo de buildout , a menudo usamos mr.developer para automatizar el proceso de obtención del código fuente para un paquete dado cuando necesitamos trabajar en él, lo que lo construye como un huevo de desarrollo y lo vincula con el despliegue mientras Trabajamos en el código.

Tenga en cuenta que el directorio .egg-info tiene un propósito específico: señalar a otras herramientas en el setuptools eco-system que su paquete está instalado y disponible. Si su paquete es una dependencia de otro huevo en su configuración, entonces esa dependencia se satisface. pip y easy_install y buildout no intentarán buscar el huevo en otro lugar.

Además de crear el directorio .egg-info , la única otra cosa que hace el comando es crear extensiones, en el lugar. Así que el comando que estás buscando es:

 setup.py build_ext --inplace 

Esto hará exactamente lo mismo que el setup.py develop pero .egg-info directorio .egg-info . Tampoco generará el archivo .pth .

No hay forma de generar solo el archivo .pth y omitir la generación del directorio .egg-info .

En términos técnicos, setup.py develop también verificará si tiene instalado el archivo setuptools site.py para admitir paquetes con espacio de nombre, pero eso no es relevante aquí.

La buena manera es mantener todos los archivos de origen dentro del directorio especial cuyo nombre es el nombre de su proyecto (los progtwigdores que usan otros idiomas mantienen su código dentro del directorio src ). Entonces, si su archivo setup.py está dentro del directorio de myproject , entonces debe mantener los archivos en myproject/myproject . Este método mantiene sus fonts separadas de otros archivos, independientemente de lo que suceda en el directorio principal.

Mi sugerencia sería utilizar la lista blanca en lugar de la lista negra: diga a las herramientas que ignoren todos los archivos, excepto los que están dentro del directorio de myproject . Creo que esta es la forma más sencilla de no tocar tus listas de ignore demasiada frecuencia.

Pruebe la opción --install-dir . También puede utilizar --build-dir para cambiar el directorio de construcción.