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

Imagine que desea desarrollar una aplicación de escritorio (no web) no trivial para el usuario final en Python. ¿Cuál es la mejor manera de estructurar la jerarquía de carpetas del proyecto?

Las características deseables son la facilidad de mantenimiento, la compatibilidad con IDE, la idoneidad para la ramificación/fusión del control de fuente y la fácil generación de paquetes de instalación.

En particular:

1. ¿Dónde pones la fuente?
2. ¿Dónde se colocan los scripts de inicio de aplicaciones?
3. ¿Dónde pones el material del proyecto IDE?
4. ¿Dónde pones las pruebas unitarias/de aceptación?
5. ¿Dónde se colocan los datos que no son de Python, como los archivos de configuración?
6. ¿Dónde coloca fuentes que no son de Python, como C++, para módulos de extensión binaria pyd/so?

Oct 11 '08 04:10 kbluck

Según la estructura del sistema de archivos de Jean-Paul Calderone de un proyecto Python :

Project/
|-- bin/
|   |-- project
|
|-- project/
|   |-- test/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |   
|   |-- __init__.py
|   |-- main.py
|
|-- setup.py
|-- README

May 13 '2011 23:05 cmcginty

Esta publicación de blog de Jean-Paul Calderone se suele dar como respuesta en #python en Freenode.

Estructura del sistema de archivos de un proyecto Python

Hacer:

• Nombra el directorio con algo relacionado con tu proyecto. Por ejemplo, si su proyecto se llama "Twisted", asigne un nombre al directorio de nivel superior para sus archivos fuente Twisted. Cuando realice lanzamientos, debe incluir un sufijo de número de versión: Twisted-2.5.
• cree un directorio Twisted/biny coloque allí sus ejecutables, si tiene alguno. No les dé una .pyextensión, incluso si son archivos fuente de Python. No incluya ningún código en ellos, excepto una importación y una llamada a una función principal definida en algún otro lugar de sus proyectos. (Ligero detalle: dado que en Windows, el intérprete se selecciona según la extensión del archivo, los usuarios de Windows en realidad quieren la extensión .py. Por lo tanto, cuando empaquete para Windows, es posible que desee agregarlo. Desafortunadamente, no existe un truco fácil de distutils que Sé que se puede automatizar este proceso. Teniendo en cuenta que en POSIX la extensión .py es solo una verruga, mientras que en Windows la falta es un error real, si su base de usuarios incluye usuarios de Windows, es posible que desee optar por tener solo el .py extensión en todas partes.)
• Si su proyecto se puede expresar como un único archivo fuente de Python, colóquelo en el directorio y asígnele un nombre relacionado con su proyecto. Por ejemplo, Twisted/twisted.py. Si necesita varios archivos fuente, cree un paquete ( Twisted/twisted/, con un vacío Twisted/twisted/__init__.py) y coloque sus archivos fuente en él. Por ejemplo, Twisted/twisted/internet.py.
• coloque sus pruebas unitarias en un subpaquete de su paquete (nota: esto significa que la opción de archivo fuente único de Python anterior fue un truco; siempre necesitará al menos otro archivo para sus pruebas unitarias). Por ejemplo, Twisted/twisted/test/. Por supuesto, conviértalo en un paquete con Twisted/twisted/test/__init__.py. Coloque pruebas en archivos como Twisted/twisted/test/test_internet.py.
• agregue Twisted/READMEy Twisted/setup.pypara explicar e instalar su software, respectivamente, si se siente bien.

No:

• coloque su fuente en un directorio llamado srco lib. Esto dificulta su ejecución sin instalación.
• coloque sus pruebas fuera de su paquete Python. Esto dificulta la ejecución de pruebas en una versión instalada.
• cree un paquete que solo tenga a __init__.pyy luego coloque todo su código en __init__.py. Simplemente cree un módulo en lugar de un paquete, es más simple.
• Intente idear trucos mágicos para que Python pueda importar su módulo o paquete sin que el usuario agregue el directorio que lo contiene a su ruta de importación (ya sea a través de PYTHONPATH o algún otro mecanismo). No manejará correctamente todos los casos y los usuarios se enojarán con usted cuando su software no funcione en su entorno.

Aug 05 '2010 23:08 Adrian

Consulte Cómo abrir un proyecto Python de la manera correcta .

Permítanme extraer la parte del diseño del proyecto de ese excelente artículo:

Al configurar un proyecto, es importante acertar con el diseño (o estructura de directorios). Un diseño sensato significa que los contribuyentes potenciales no tienen que pasar una eternidad buscando un fragmento de código; Las ubicaciones de los archivos son intuitivas. Dado que estamos tratando con un proyecto existente, significa que probablemente necesitarás mover algunas cosas.

Empecemos por arriba. La mayoría de los proyectos tienen varios archivos de nivel superior (como setup.py, README.md, requisitos.txt, etc.). Entonces hay tres directorios que todo proyecto debería tener:

• Un directorio de documentos que contiene documentación del proyecto.
• Un directorio nombrado con el nombre del proyecto que almacena el paquete Python real.
• Un directorio de prueba en uno de dos lugares.
  • En el directorio del paquete que contiene el código de prueba y los recursos.
  • Como directorio independiente de nivel superior. Para tener una mejor idea de cómo deben organizarse sus archivos, aquí hay una instantánea simplificada del diseño de uno de mis proyectos, Sandman:

$ pwd
~/code/sandman
$ tree
.
|- LICENSE
|- README.md
|- TODO.md
|- docs
|   |-- conf.py
|   |-- generated
|   |-- index.rst
|   |-- installation.rst
|   |-- modules.rst
|   |-- quickstart.rst
|   |-- sandman.rst
|- requirements.txt
|- sandman
|   |-- __init__.py
|   |-- exception.py
|   |-- model.py
|   |-- sandman.py
|   |-- test
|       |-- models.py
|       |-- test_sandman.py
|- setup.py

Como puede ver, hay algunos archivos de nivel superior, un directorio de documentos (el generado es un directorio vacío donde Sphinx colocará la documentación generada), un directorio de Sandman y un directorio de prueba en Sandman.

Nov 09 '2013 02:11 David C. Bishop