Il y a deux types de "projets" Django que j'ai dans mon ~/projects/répertoire, les deux ont une structure un peu différente:
- Sites Web autonomes
- Applications enfichables
Site Web autonome
Principalement des projets privés, mais ce n'est pas obligatoire. Cela ressemble généralement à ceci:
~/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
...
Paramètres
Les principaux paramètres sont ceux de production. D'autres fichiers (par exemple staging.py,
development.py) importent simplement tout à partir de production.pyet ne remplacent que les variables nécessaires.
Pour chaque environnement, il existe des fichiers de paramètres distincts, par exemple. production, développement. J'ai quelques projets que j'ai également testés (pour le testeur), la mise en scène (comme vérification avant le déploiement final) et les paramètres d'heroku (pour le déploiement sur heroku).
Exigences
Je spécifie plutôt les exigences directement dans setup.py. Seuls ceux requis pour l'environnement de développement / test que j'ai dans requirements_dev.txt.
Certains services (par exemple heroku) nécessitent d'avoir requirements.txtdans le répertoire racine.
setup.py
Utile lors du déploiement d'un projet à l'aide de setuptools. Cela ajoute manage.pyà PATH, donc je peux courir manage.pydirectement (n'importe où).
Applications spécifiques au projet
J'avais l'habitude de mettre ces applications dans un project_name/apps/répertoire et de les importer à l'aide d'importations relatives.
Modèles / static / locale / fichiers de tests
Je mets ces modèles et fichiers statiques dans le répertoire global templates / static, pas dans chaque application. Ces fichiers sont généralement modifiés par des personnes, qui ne se soucient pas du tout de la structure du code du projet ou de Python. Si vous êtes un développeur full-stack travaillant seul ou dans une petite équipe, vous pouvez créer des modèles / répertoire statique par application. C'est vraiment juste une question de goût.
Il en va de même pour les paramètres régionaux, bien qu'il soit parfois pratique de créer un répertoire de paramètres régionaux distinct.
Il est généralement préférable de placer les tests dans chaque application, mais il existe généralement de nombreux tests d'intégration / fonctionnels qui testent plus d'applications fonctionnant ensemble, donc le répertoire de tests global a du sens.
Répertoire Tmp
Il existe un répertoire temporaire à la racine du projet, exclu du VCS. Il est utilisé pour stocker des fichiers multimédias / statiques et une base de données sqlite pendant le développement. Tout dans tmp peut être supprimé à tout moment sans aucun problème.
Virtualenv
Je préfère virtualenvwrapperet place tous les venv dans le ~/.venvsrépertoire, mais vous pouvez le placer à l'intérieur tmp/pour le garder ensemble.
Modèle de projet
J'ai créé un modèle de projet pour cette configuration, django-start-template
Déploiement
Le déploiement de ce projet est le suivant:
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
Vous pouvez utiliser à la rsyncplace de git, mais vous devez quand même exécuter un lot de commandes pour mettre à jour votre environnement.
Récemment, j'ai créé une [django-deploy][2]application, qui me permet d'exécuter une seule commande de gestion pour mettre à jour l'environnement, mais je ne l'ai utilisée que pour un projet et je suis toujours en train de l'expérimenter.
Croquis et brouillons
Brouillon de modèles que je place dans le templates/répertoire global . Je suppose que l'on peut créer un dossier sketches/à la racine du projet, mais je ne l'ai pas encore utilisé.
Application enfichable
Ces applications sont généralement prêtes à être publiées en open source. J'ai pris l'exemple ci - dessous de django-forme
~/projects/django-app/
docs/
app/
tests/
example_project/
LICENCE
MANIFEST.in
README.md
setup.py
pytest.ini
tox.ini
.travis.yml
...
Le nom des répertoires est clair (j'espère). Je place les fichiers de test en dehors du répertoire de l'application, mais cela n'a vraiment pas d'importance. Il est important de fournir READMEet setup.py, donc le package est facilement installé via pip.