web-dev-qa-db-fra.com

Méthode recommandée pour la structure de répertoires de travail du projet Django

Je sais qu'il n'y a pas vraiment de bonne façon. Cependant, j’ai constaté qu’il était difficile de créer une structure de répertoires qui fonctionne bien et reste propre pour tous les développeurs et administrateurs. Il existe une structure standard dans la plupart des projets sur github. Mais cela ne montre pas comment organiser d'autres fichiers et tous les projets sur PC.

Quel est le moyen le plus pratique d'organiser tous ces répertoires sur une machine de développement? Comment les nommez-vous et comment vous connectez-vous et déployez-vous cela sur le serveur?

  • projets (tous les projets sur lesquels vous travaillez)
  • fichiers source (l'application elle-même)
  • copie de travail du dépôt (j'utilise git)
  • environnement virtuel (je préfère placer ceci près du projet)
  • racine statique (pour les fichiers statiques compilés)
  • racine du média (pour les fichiers multimédias téléchargés)
  • README
  • LICENCE
  • documents
  • croquis
  • exemples (un exemple de projet utilisant l'application fournie par ce projet)
  • base de données (si sqlite est utilisé)
  • tout ce dont vous avez généralement besoin pour réussir vos travaux sur le projet

Les problèmes que je veux résoudre:

  • Bons noms de répertoires pour que leur but soit clair.
  • Conserver tous les fichiers de projet (y compris virtualenv) au même endroit afin de pouvoir facilement copier, déplacer, archiver, supprimer tout le projet ou estimer l'utilisation de l'espace disque.
  • Créer plusieurs copies de certains ensembles de fichiers sélectionnés, tels qu'une application entière, un référentiel ou virtualenv, tout en conservant une copie unique d'un autre fichier que je ne souhaite pas cloner.
  • Déployer le bon ensemble de fichiers sur le serveur en rsynchronisant simplement un répertoire sélectionné.
djangodirectory-structureorganizationproject-structure
135
raacer

Il y a deux types de Django _ "projets" que j'ai dans mon répertoire ~/projects/, les deux ont une structure légèrement différente.

  • Sites Web autonomes
  • Applications enfichables

Site Web autonome

Principalement des projets privés, mais pas nécessairement. Cela ressemble habituellement à 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. Les autres fichiers (par exemple staging.py, development.py) importent simplement tout ce qui se trouve à partir de production.py et ne remplacent que les variables nécessaires.

Pour chaque environnement, il existe des fichiers de paramètres distincts, par exemple. production, développement. Dans certains projets, j’ai également testé (pour test runner), staging (comme vérification avant le déploiement final) et 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.txt dans le répertoire racine.

setup.py

Utile lors du déploiement de projet avec setuptools. Il ajoute manage.py à PATH afin que je puisse exécuter manage.py directement (n'importe où).

Applications spécifiques au projet

J'avais l'habitude de mettre ces applications dans le répertoire project_name/apps/ et de les importer à l'aide d'importations relatifs.

Fichiers modèles/statique/locale/tests

Je mets ces modèles et fichiers statiques dans le répertoire global templates/static, et non dans chaque application. Ces fichiers sont généralement édités par des personnes qui ne se soucient guère de la structure de code du projet ni de python. Si vous êtes un développeur de pile complète travaillant seul ou dans une petite équipe, vous pouvez créer un répertoire de modèles/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 un plus grand nombre d’applications fonctionnant ensemble. Par conséquent, le répertoire des tests globaux est logique.

Répertoire tmp

Il existe un répertoire temporaire à la racine du projet, exclu de 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 virtualenvwrapper et place tous les éléments dans le répertoire ~/.venvs, mais vous pouvez le placer dans 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 rsync au lieu de git, mais vous devez néanmoins exécuter un lot de commandes pour mettre à jour votre environnement.

Récemment, j'ai créé l'application [Django-deploy][2], 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 l'expérimente encore.

Esquisses et brouillons

Ébauche de modèles que je place dans le répertoire global templates/. Je suppose que l’on peut créer un dossier sketches/ à la racine du projet, mais ne l’a pas encore utilisé.

Application enfichable

Ces applications sont généralement préparées pour ê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 mets des fichiers de test hors du répertoire de l'application, mais cela n'a pas d'importance. Il est important de fournir README et setup.py, afin que le paquet soit facilement installé via pip.

212
Tomáš Ehrlich

Ma réponse est inspirée par ma propre expérience professionnelle, et principalement dans le livre Two Scoops of Django que je recommande vivement, et où vous pouvez trouver une explication plus détaillée de tout. Je vais juste répondre à certains points, et toute amélioration ou correction sera la bienvenue. Mais il peut aussi y avoir des manières plus correctes d'atteindre le même but.

Projets
J'ai un dossier principal dans mon répertoire personnel où je gère tous les projets sur lesquels je travaille.

Fichiers sources
J'utilise personnellement la racine de projet Django en tant que racine de référentiel de mes projets. Mais dans le livre est recommandé de séparer les deux choses. Je pense que cette approche est meilleure et j'espère donc pouvoir commencer à effectuer le changement progressivement dans mes projets.

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

Dépôt
Git ou Mercurial semblent être les systèmes de contrôle de versions les plus populaires parmi les développeurs de Django. Et les services d'hébergement les plus populaires pour les sauvegardes GitHub et Bitbucket .

Environnement virtuel
J'utilise virtualenv et virtualenvwrapper. Après avoir installé le second, vous devez configurer votre répertoire de travail. Le mien se trouve dans mon répertoire /home/envs , comme recommandé dans le guide d'installation de virtualenvwrapper. Mais je ne pense pas que le plus important est de savoir où il se trouve. La chose la plus importante lorsque vous travaillez avec des environnements virtuels est de maintenir le fichier requirements.txt à jour.

pip freeze -l > requirements.txt

Racine statique
Dossier de projet

Racine de média
Dossier de projet

README
Racine du référentiel

LICENCE
Racine du référentiel

Documents
Racine du référentiel. Ces packages python peuvent vous aider à gérer plus facilement votre documentation:

Croquis

Exemples

Base de données

14
cor

Je n'aime pas créer un nouveau répertoire settings/. J'ajoute simplement des fichiers nommés settings_dev.py et settings_production.py donc je n'ai pas à modifier le BASE_DIR. L'approche ci-dessous augmente la structure par défaut au lieu de la modifier.

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

Je pense que ce:

    settings.py
    settings_dev.py
    settings_production.py

c'est mieux que ça:

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

Ce concept s'applique également à d'autres fichiers.

Je place généralement node_modules/ et bower_components/ dans le répertoire du projet, dans le dossier static/ par défaut.

Parfois, un répertoire vendor/ pour les sous-modules Git, mais généralement je les place dans le dossier static/.

7
isar

Voici ce que je suis sur mon système.

  1. Tous les projets : Il existe un répertoire de projets dans mon dossier personnel , à savoir ~/projects. Tous les projets reposent à l'intérieur.

  2. Projet individuel : Je suis un modèle de structure normalisé utilisé par de nombreux développeurs appelés Django-skel pour des projets individuels. Il s’occupe essentiellement de tous vos fichiers statiques, de vos fichiers multimédias, etc.

  3. Environnement virtuel : J'ai un dossier virtualenvs dans ma maison pour tout stocker. environnements virtuels dans le système, par exemple ~/virtualenvs. Cela me donne la flexibilité de savoir ce que tous les environnements virtuels que j'ai et que je peux regarder peuvent être utilisés facilement

Les 3 ci-dessus sont les partitions principales de Mon environnement de travail.

Toutes les autres parties que vous avez mentionnées dépendent principalement du projet à la base (c’est-à-dire que vous pouvez utiliser différentes bases de données pour différents projets). Ils devraient donc résider dans leurs projets individuels.

2
Sahil kalra

Conformément à la documentation Django, la structure de répertoire appropriée à suivre est la suivante:

[projectname]/                  <- project root
├── [projectname]/              <- Django root
│   ├── __init__.py
│   ├── settings/
│   │   ├── common.py
│   │   ├── development.py
│   │   ├── i18n.py
│   │   ├── __init__.py
│   │   └── production.py
│   ├── urls.py
│   └── wsgi.py
├── apps/
│   └── __init__.py
├── configs/
│   ├── Apache2_vhost.sample
│   └── README
├── doc/
│   ├── Makefile
│   └── source/
│       └── *snap*
├── manage.py
├── README.rst
├── run/
│   ├── media/
│   │   └── README
│   ├── README
│   └── static/
│       └── README
├── static/
│   └── README
└── templates/
    ├── base.html
    ├── core
    │   └── login.html
    └── README

Reportez-vous à https://Django-project-skeleton.readthedocs.io/en/latest/structure.html pour obtenir la dernière structure de répertoires.

1
Sachin Vardhan