it-swarm.com.de

Best Practice für Django Projektarbeitsverzeichnisstruktur

Ich weiß, dass es keinen richtigen Weg gibt. Ich habe jedoch festgestellt, dass es schwierig ist, eine Verzeichnisstruktur zu erstellen, die gut funktioniert und für jeden Entwickler und Administrator sauber bleibt. In den meisten Projekten auf Github gibt es eine Standardstruktur. Es zeigt jedoch keine Möglichkeit, andere Dateien und alle Projekte auf dem PC zu organisieren.

Was ist der bequemste Weg, um all diese Verzeichnisse auf der Entwicklungsmaschine zu organisieren? Wie benennen Sie sie und wie stellen Sie eine Verbindung her und stellen Sie diese auf dem Server bereit?

  • projekte (alle Projekte, an denen Sie arbeiten)
  • quelldateien (die Anwendung selbst)
  • arbeitskopie des Projektarchivs (ich benutze git)
  • virtuelle Umgebung (Ich bevorzuge es, diese in der Nähe des Projekts zu platzieren)
  • statisches Stammverzeichnis (für kompilierte statische Dateien)
  • medienstamm (für hochgeladene Mediendateien)
  • README
  • LIZENZ
  • unterlagen
  • skizzen
  • examples (ein Beispielprojekt, das die von diesem Projekt bereitgestellte Anwendung verwendet)
  • datenbank (falls SQLite verwendet wird)
  • alles andere, was Sie normalerweise für eine erfolgreiche Projektarbeit benötigen

Die Probleme, die ich lösen möchte:

  • Gute Namen von Verzeichnissen, damit deren Zweck klar ist.
  • Bewahren Sie alle Projektdateien (einschließlich virtualenv) an einem Ort auf, damit Sie problemlos das gesamte Projekt kopieren, verschieben, archivieren, entfernen oder den Speicherplatzbedarf schätzen können.
  • Erstellen mehrerer Kopien einiger ausgewählter Dateigruppen, z. B. der gesamten Anwendung, des Repositorys oder von Virtualenv, und Beibehalten einer einzelnen Kopie anderer Dateien, die nicht geklont werden sollen.
  • Bereitstellen der richtigen Dateigruppe auf dem Server durch einfaches Synchronisieren des ausgewählten Verzeichnisses.
135
raacer

Es gibt zwei Arten von Django "Projekten", die ich in meinem ~/projects/ - Verzeichnis habe. Beide haben eine etwas andere Struktur:

  • Eigenständige Websites
  • Steckbare Anwendungen

Standalone-Website

Meist private Projekte, muss es aber nicht sein. Es sieht normalerweise so aus:

~/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
...

Die Einstellungen

Die Haupteinstellungen sind Produktionseinstellungen. Andere Dateien (zB staging.py, development.py) Importieren einfach alles aus production.py Und überschreiben nur die notwendigen Variablen.

Für jede Umgebung gibt es separate Einstellungsdateien, z. Produktion, Entwicklung. Ich habe einige Projekte, die ich auch testen (für Testläufer), bereitstellen (als Überprüfung vor der endgültigen Bereitstellung) und Heroku-Einstellungen (für die Bereitstellung auf Heroku).

Bedarf

Ich spezifiziere die Anforderungen lieber direkt in setup.py. Nur die für die Entwicklungs-/Testumgebung erforderlichen sind in requirements_dev.txt Enthalten.

Für einige Dienste (z. B. Heroku) muss sich requirements.txt Im Stammverzeichnis befinden.

setup.py

Nützlich beim Bereitstellen von Projekten mit setuptools. Es fügt manage.py Zu PATH hinzu, so dass ich manage.py Direkt (überall) ausführen kann.

Projektspezifische Apps

Früher habe ich diese Apps in das Verzeichnis project_name/apps/ Gestellt und sie mit relativen Importen importiert.

Templates/static/locale/testet Dateien

Ich habe diese Vorlagen und statischen Dateien in das globale Verzeichnis templates/static gestellt, nicht in jede App. Diese Dateien werden normalerweise von Personen bearbeitet, denen die Projektcodestruktur oder python überhaupt nicht wichtig ist. Wenn Sie ein Full-Stack-Entwickler sind, der alleine oder in einem kleinen Team arbeitet, können Sie pro erstellen -app templates/static directory. Es ist wirklich nur Geschmackssache.

Dasselbe gilt für das Gebietsschema, obwohl es manchmal bequem ist, ein separates Gebietsschema-Verzeichnis zu erstellen.

Tests sind normalerweise besser in jeder App zu platzieren, aber normalerweise gibt es viele Integrations-/Funktionstests, mit denen mehr Apps zusammenarbeiten. Daher ist ein globales Testverzeichnis sinnvoll.

Tmp-Verzeichnis

Das Projektstammverzeichnis enthält ein temporäres Verzeichnis, das von VCS ausgeschlossen ist. Es wird verwendet, um Medien-/statische Dateien und SQLite-Datenbanken während der Entwicklung zu speichern. Alles in tmp kann jederzeit problemlos gelöscht werden.

Virtualenv

Ich bevorzuge virtualenvwrapper und stelle alle venvs in das Verzeichnis ~/.venvs, Aber Sie können es in tmp/ Einfügen, um es zusammen zu halten.

Projektvorlage

Ich habe eine Projektvorlage für dieses Setup erstellt, Django-Startvorlage

Einsatz

Die Bereitstellung dieses Projekts ist wie folgt:

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

Sie können rsync anstelle von git verwenden, müssen jedoch eine Reihe von Befehlen ausführen, um Ihre Umgebung zu aktualisieren.

Kürzlich habe ich die App [Django-deploy][2] Erstellt, mit der ich einen einzelnen Verwaltungsbefehl ausführen kann, um die Umgebung zu aktualisieren. Ich habe sie jedoch nur für ein Projekt verwendet und experimentiere immer noch damit.

Skizzen und Entwürfe

Vorlagenentwurf, den ich in das globale templates/ - Verzeichnis lege. Ich vermute, man kann einen Ordner sketches/ Im Projektstamm erstellen, hat ihn aber noch nicht verwendet.

Steckbare Anwendung

Diese Apps sind normalerweise für die Veröffentlichung als Open Source vorbereitet. Ich habe unten ein Beispiel von Django-forme genommen

~/projects/Django-app/

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

Name der Verzeichnisse ist klar (hoffe ich). Ich habe Testdateien außerhalb des App-Verzeichnisses abgelegt, aber das spielt wirklich keine Rolle. Es ist wichtig, README und setup.py Anzugeben, damit das Paket problemlos über pip installiert werden kann.

212
Tomáš Ehrlich

Meine Antwort basiert auf meiner eigenen Arbeitserfahrung und hauptsächlich auf dem Buch Two Scoops of Django , das ich wärmstens empfehlen kann und in dem Sie eine detailliertere Erklärung für alles finden. Ich werde nur einige der Punkte beantworten, und jede Verbesserung oder Korrektur wird begrüßt. Es kann aber auch korrektere Arten geben, um den gleichen Zweck zu erreichen.

Projekte
Ich habe einen Hauptordner in meinem persönlichen Verzeichnis, in dem ich alle Projekte pflege, an denen ich arbeite.

Quelldateien
Ich persönlich verwende das Projektstammverzeichnis Django=) als Repository-Stamm meiner Projekte. In dem Buch wird jedoch empfohlen, beide Dinge zu trennen. Ich denke, dass dies ein besserer Ansatz ist, also ich Ich hoffe, dass ich meine Projekte schrittweise ändern kann.

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

Repository
Git oder Mercurial scheinen die beliebtesten Versionskontrollsysteme unter Django Entwicklern zu sein. Und die beliebtesten Hosting-Dienste für Backups GitHub und Bitbucket .

Virtuelle Umgebung
Ich verwende virtualenv und virtualenvwrapper. Nach der Installation des zweiten müssen Sie Ihr Arbeitsverzeichnis einrichten. Meins befindet sich in meinem /home/envs Verzeichnis, wie es in der Installationsanleitung von virtualenvwrapper empfohlen wird. Aber ich denke nicht, dass das Wichtigste ist, wo es platziert ist. Das Wichtigste bei der Arbeit mit virtuellen Umgebungen ist, die Datei requirements.txt auf dem neuesten Stand zu halten.

pip freeze -l > requirements.txt 

Statische Wurzel
Projektordner

Media Root
Projektordner

[~ # ~] readme [~ # ~]
Repository-Stammverzeichnis

[~ # ~] Lizenz [~ # ~]
Repository-Stammverzeichnis

Dokumente
Repository-Stammverzeichnis. Mit diesen python Paketen können Sie die Verwaltung Ihrer Dokumentation vereinfachen:

Skizzen

Beispiele

Datenbank

14
cor

Ich möchte kein neues settings/ - Verzeichnis erstellen. Ich füge einfach Dateien mit den Namen settings_dev.py Und settings_production.py Hinzu, damit ich den BASE_DIR Nicht bearbeiten muss. Der folgende Ansatz erhöht die Standardstruktur, anstatt sie zu ändern.

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

Ich denke das:

    settings.py
    settings_dev.py
    settings_production.py

ist besser als das:

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

Dieses Konzept gilt auch für andere Dateien.


Normalerweise lege ich node_modules/ Und bower_components/ Im Projektverzeichnis des Standardordners static/ Ab.

Irgendwann ein vendor/ - Verzeichnis für Git-Submodule, aber normalerweise lege ich sie in den Ordner static/.

7
isar

Hier ist, was ich auf meinem System verfolge.

  1. Alle Projekte: In meinem Home-Ordner befindet sich ein Projektverzeichnis d. H. ~/projects. Alle Projekte ruhen darin.

  2. Individuelles Projekt: Ich folge einer standardisierten Strukturvorlage, die von vielen Entwicklern als Django-Skel für einzelne Projekte verwendet wird. Es kümmert sich im Grunde um alle Ihre statischen Dateien und Mediendateien und alles.

  3. Virtuelle Umgebung: Ich habe einen Ordner für virtuelle Umgebungen in meinem Zuhause um alle virtuellen Umgebungen im System zu speichern, d. H. ~/virtualenvs. Dies gibt mir Flexibilität dass ich weiß, welche virtuellen Umgebungen ich habe und welche ich einfach nutzen kann

Die obigen 3 sind die Hauptpartitionen meiner Arbeitsumgebung.

Alle anderen Teile, die Sie erwähnt haben sind größtenteils von Projekt zu Projekt abhängig (d. H. Sie könnten verschiedene Datenbanken für verschiedene Projekte verwenden). Sie sollten also in ihren individuellen Projekten wohnen.

2
Sahil kalra

Gemäß der Django Dokumentation kann folgende Verzeichnisstruktur verwendet werden:

[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

Die neueste Verzeichnisstruktur finden Sie unter https://Django-project-skeleton.readthedocs.io/en/latest/structure.html .

1
Sachin Vardhan