tutorial - ejemplos de proyectos en django

Práctica recomendada para la estructura de directorios de trabajo del proyecto Django

Question

Sé que en realidad no hay una única forma correcta. Sin embargo, he descubierto que es difícil crear una estructura de directorios que funcione bien y permanezca limpia para todos los desarrolladores y administradores. Existe una estructura estándar en la mayoría de los proyectos en github. Pero no muestra una forma de organizar otros archivos y todos los proyectos en la PC.

¿Cuál es la forma más conveniente de organizar todos estos directorios en la máquina de desarrollo? ¿Cómo los nombra, y cómo se conecta e implementa esto en el servidor?

• proyectos (todos los proyectos en los que estás trabajando)
• archivos fuente (la aplicación en sí)
• copia de trabajo del repositorio (yo uso git)
• entorno virtual (prefiero colocar esto cerca del proyecto)
• raíz estática (para archivos estáticos compilados)
• raíz de medios (para archivos multimedia cargados)
• README
• LICENCIA
• documentos
• bocetos
• ejemplos (un proyecto de ejemplo que utiliza la aplicación proporcionada por este proyecto)
• base de datos (en caso de que se use sqlite)
• cualquier otra cosa que generalmente necesite para un trabajo exitoso en el proyecto

Los problemas que quiero resolver:

• Buenos nombres de directorios para que su propósito sea claro.
• Mantener todos los archivos de proyecto (incluido virtualenv) en un solo lugar, para que pueda copiar, mover, archivar, eliminar todo el proyecto o estimar el uso de espacio en disco fácilmente.
• Crear copias múltiples de algunos conjuntos de archivos seleccionados, como la aplicación completa, el repositorio o virtualenv, mientras conservo una copia única de otros archivos que no deseo clonar.
• Desplegar el conjunto correcto de archivos en el servidor simplemente sincronizando el directorio seleccionado.

Answer 1

Esto es lo que sigo en Mi sistema.

1. Todos los proyectos : hay un directorio de proyectos en mi carpeta de inicio, es decir ~/projects . Todos los proyectos descansan dentro de él.

2. Proyecto individual : sigo una plantilla de estructura estandarizada utilizada por muchos desarrolladores llamada django-skel para proyectos individuales. Básicamente se ocupa de todos tus archivos estáticos y archivos multimedia, y todo.

3. Entorno virtual : tengo una carpeta virtualenvs dentro de mi casa para almacenar todos los entornos virtuales en el sistema, es decir ~/virtualenvs . Esto me da flexibilidad , sé lo que todos los entornos virtuales que tengo y puedo ver usar fácilmente

Los 3 anteriores son las particiones principales de Mi entorno de trabajo.

Todas las otras partes que mencionaste dependen principalmente de un proyecto a proyecto (es decir, puedes usar diferentes bases de datos para diferentes proyectos). Entonces deberían residir en sus proyectos individuales.

Answer 2

Mi respuesta está inspirada en mi propia experiencia laboral, y principalmente en el libro Two Scoops of Django, que recomiendo encarecidamente, y donde puede encontrar una explicación más detallada de todo. Solo responderé algunos de los puntos, y cualquier mejora o corrección será bienvenida. Pero también puede haber más maniobras correctas para lograr el mismo propósito.

Proyectos
Tengo una carpeta principal en mi directorio personal donde mantengo todos los proyectos en los que estoy trabajando.

Archivos fuente
Yo personalmente uso la raíz del proyecto django como raíz de repositorio de mis proyectos. Pero en el libro se recomienda separar ambas cosas. Creo que este es un mejor enfoque, así que espero comenzar a hacer el cambio progresivamente en mis proyectos.

project_repository_folder/
.gitignore
Makefile
LICENSE.rst
docs/
README.rst
requirements.txt
project_folder/
manage.py
media/
app-1/
app-2/
...
app-n/
static/
templates/
project/
__init__.py
settings/
__init__.py
base.py
dev.py
local.py
test.py
production.py
ulrs.py
wsgi.py

Repositorio
Git o Mercurial parecen ser los sistemas de control de versiones más populares entre los desarrolladores de Django. Y los servicios de alojamiento más populares para copias de seguridad GitHub y Bitbucket .

Ambiente virtual
Yo uso virtualenv y virtualenvwrapper. Después de instalar el segundo, debe configurar su directorio de trabajo. El mío está en mi directorio / home / envs , como se recomienda en la guía de instalación virtualenvwrapper. Pero no creo que lo más importante sea dónde se ubica. Lo más importante al trabajar con entornos virtuales es mantener el archivo requirements.txt actualizado.

pip freeze -l > requirements.txt

Raíz estática
Carpeta de proyecto

Media Root
Carpeta de proyecto

README
Raíz del repositorio

LICENCIA
Raíz del repositorio

Documentos
Raíz del repositorio Estos paquetes de python pueden ayudarlo a hacer que su documentación sea más fácil:

• reStructuredText
• Sphinx

Bocetos

Ejemplos

Base de datos

Answer 3

No me gusta crear una nueva settings/ directorio. Simplemente agrego archivos llamados settings_dev.py y settings_production.py para no tener que editar BASE_DIR . El siguiente enfoque aumenta la estructura predeterminada en lugar de cambiarla.

mysite/ # Project
conf/
locale/
en_US/
fr_FR/
it_IT/
mysite/
__init__.py
settings.py
settings_dev.py
settings_production.py
urls.py
wsgi.py
static/
admin/
css/ # Custom back end styles
css/ # Project front end styles
fonts/
images/
js/
sass/
staticfiles/
templates/ # Project templates
includes/
footer.html
header.html
index.html
myapp/ # Application
core/
migrations/
__init__.py
templates/ # Application templates
myapp/
index.html
static/
myapp/
js/
css/
images/
__init__.py
admin.py
apps.py
forms.py
models.py
models_foo.py
models_bar.py
views.py
templatetags/ # Application with custom context processors and template tags
__init__.py
context_processors.py
templatetags/
__init__.py
templatetag_extras.py
gulpfile.js
manage.py
requirements.txt

Pienso esto:

 settings.py
settings_dev.py
settings_production.py

es mejor que esto:

 settings/__init__.py
settings/base.py
settings/dev.py
settings/production.py

Este concepto se aplica a otros archivos también.

Normalmente bower_components/ node_modules/ y bower_components/ en el directorio del proyecto dentro de la carpeta static/ carpeta predeterminada.

En algún momento un vendor/ directorio para Git Submodules, pero generalmente los coloco en la carpeta static/ .

Answer 4

Hay dos tipos de "proyectos" de Django que tengo en mi directorio ~/projects/ , ambos tienen una estructura un poco diferente.

• Sitios web independientes
• Aplicaciones conectables

Sitio web independiente

En su mayoría proyectos privados, pero no tiene por qué serlo. Por lo general, se ve así:

~/projects/project_name/
docs/ # documentation
scripts/
manage.py # installed to PATH via setup.py
project_name/ # project dir (the one which django-admin.py creates)
apps/ # project-specific applications
accounts/ # most frequent app, with custom user model
__init__.py
...
settings/ # settings for different environments, see below
__init__.py
production.py
development.py
...
__init__.py # contains project version
urls.py
wsgi.py
static/ # site-specific static files
templates/ # site-specific templates
tests/ # site-specific tests (mostly in-browser ones)
tmp/ # excluded from git
setup.py
requirements.txt
requirements_dev.txt
pytest.ini
...

Configuraciones

Los ajustes principales son de producción. Otros archivos (p. Ej., staging.py , development.py ) simplemente importan todo de production.py y reemplazan solo las variables necesarias.

Para cada entorno, hay archivos de configuración separados, por ej. producción, desarrollo. En algunos proyectos también tengo pruebas (para el corredor de prueba), puesta en escena (como comprobación antes de la implementación final) y heroku (para implementar en heroku).

Requisitos

Prefiero especificar los requisitos en setup.py directamente. Solo los necesarios para el entorno de desarrollo / prueba que tengo en requirements_dev.txt .

Algunos servicios (por ejemplo, heroku) requieren tener requirements.txt en el directorio raíz.

setup.py

Útil al implementar proyectos usando setuptools . Agrega manage.py a PATH , por lo que puedo ejecutar manage.py directamente (en cualquier lugar).

Aplicaciones específicas del proyecto

Solía ​​poner estas aplicaciones en project_name/apps/ directory e importarlas usando importaciones relativas.

Plantillas / archivos estáticos / locale / pruebas

Puse estas plantillas y archivos estáticos en plantillas globales / directorio estático, no dentro de cada aplicación. Estos archivos generalmente son editados por personas que no se preocupan por la estructura del código del proyecto o python en absoluto. Si es un desarrollador de pila completa que trabaja solo o en un equipo pequeño, puede crear plantillas / directorio estático. Es solo una cuestión de gusto.

Lo mismo se aplica a la configuración regional, aunque a veces es conveniente crear un directorio local por separado.

Por lo general, es mejor colocar las pruebas dentro de cada aplicación, pero generalmente hay muchas pruebas de integración / funcionalidades que prueban más aplicaciones trabajando juntas, por lo que el directorio de pruebas globales tiene sentido.

Tmp directorio

Hay un directorio temporal en la raíz del proyecto, excluido de VCS. Se usa para almacenar archivos multimedia / estáticos y base de datos sqlite durante el desarrollo. Todo en tmp se puede eliminar en cualquier momento sin ningún problema.

Virtualenv

Prefiero virtualenvwrapper y coloco todos los vengadores en el directorio ~/.venvs , pero puede colocarlo dentro de tmp/ para mantenerlo unido.

Plantilla de proyecto

Creé una plantilla de proyecto para esta configuración, django-start-template

Despliegue

La implementación de este proyecto es la siguiente:

source $VENV/bin/activate
export DJANGO_SETTINGS_MODULE=project_name.settings.production
git pull
pip install -r requirements.txt
# Update database, static files, locales
manage.py syncdb --noinput
manage.py migrate
manage.py collectstatic --noinput
manage.py makemessages -a
manage.py compilemessages
# restart wsgi
touch project_name/wsgi.py

Puede usar rsync lugar de git , pero aún necesita ejecutar un lote de comandos para actualizar su entorno.

Recientemente, hice la aplicación [django-deploy][2] , que me permite ejecutar un solo comando de administración para actualizar el entorno, pero lo he usado solo para un proyecto y todavía estoy experimentando con él.

Bocetos y borradores

Borrador de plantillas que coloco dentro de las templates/ directorio globales. Creo que uno puede crear sketches/ carpeta sketches/ en raíz del proyecto, pero aún no lo ha usado.

Aplicación conectable

Estas aplicaciones generalmente están preparadas para publicar como de código abierto. A continuación, tomé el ejemplo de django-forme

~/projects/django-app/
docs/
app/
tests/
example_project/
LICENCE
MANIFEST.in
README.md
setup.py
pytest.ini
tox.ini
.travis.yml
...

El nombre de los directorios es claro (espero). Puse archivos de prueba fuera del directorio de la aplicación, pero realmente no importa. Es importante proporcionar README y setup.py , para que el paquete se instale fácilmente a través de pip .