Die 10 häufigsten Fehler, die Django-Entwickler machen

In diesem Tutorial sehen wir uns einige häufige Fehler an, die häufig von Django-Entwicklern gemacht werden, und Möglichkeiten, sie zu vermeiden. Dieses Tutorial ist selbst dann nützlich, wenn Sie ein erfahrener Django-Entwickler sind, da Fehler, wie das Beibehalten unüberschaubar großer Einstellungen oder Namenskonflikte in statischen Assets, nicht nur auf neue Entwickler beschränkt sind, die ihren ersten Versuch mit Django wagen.

Django ist ein kostenloses und quelloffenes Python-Webframework, das häufig auftretende Entwicklungsherausforderungen hilfreich löst und es Ihnen ermöglicht, flexible, gut strukturierte Anwendungen zu erstellen. Django hat viele moderne Funktionen, die sofort einsatzbereit sind. Für mich persönlich machten der Admin, das Object Relational Mapping Tool (ORM), das Routing und die Templating-Funktionen Django zu meiner ersten Wahl, weil Anwendungen viel Arbeit erfordern und ich, obwohl ich meinen Job so viel Spaß mache wie jeder Entwickler, ausgeben möchte so wenig Zeit wie möglich für diese sich wiederholenden grundlegenden Aufgaben. Mit Django können Sie all dies tun, ohne Kompromisse bei der Flexibilität einzugehen.

Das Killer-Feature von Django ist eine leistungsstarke, konfigurierbare Admin-Oberfläche, die automatisch (automagisch?) aus den Schema- und Admin-Panel-Modellen Ihrer Modelle erstellt wird, sodass Sie sich wie ein Zauberer fühlen. Über die Admin-Oberfläche kann ein Benutzer viele Dinge konfigurieren, darunter die Zugriffskontrollliste (ACL), Berechtigungen und Aktionen auf Zeilenebene, Filter, Bestellungen, Widgets, Formulare, zusätzliche URL-Helfer und alles andere, was Sie sich vorstellen können. Ich glaube, dass jede Anwendung ein Admin-Panel benötigt – falls noch nicht geschehen, ist es nur eine Frage der Zeit, bis Ihre Basisanwendung eines benötigt. Mit Django Admin können Sie schnell und flexibel einen erstellen.

Django verfügt über ein leistungsstarkes ORM, das sofort mit allen wichtigen Datenbanken funktioniert. Da es faul ist, greift es im Gegensatz zu anderen ORMs nur dann auf Ihre Datenbank zu, wenn Sie es brauchen. Es unterstützt alle wichtigen SQL-Anweisungen (und -Funktionen), die Sie aus Ihrem Python-Quellcode verwenden können, und fühlt sich aufgrund der Python-Funktionen sehr wohl.

Die Templating-Engine von Django ist gleichzeitig sehr flexibel und leistungsstark. Sie können viele Standardfilter und Tags verwenden sowie Ihre neuen benutzerdefinierten Filter und Tags für Ihr Projekt erstellen. Django unterstützt andere Vorlagen-Engines sowie Django-Vorlagen und bietet eine API für die einfache Integration anderer Vorlagen-Engines durch standardmäßige Verknüpfungsfunktionen für die Verarbeitung von Vorlagen.

Django hat viele andere große Funktionen wie einen URL-Router, der eingehende Anfragen analysieren und neue URLs aus einem Router-Schema erstellen kann. Insgesamt ist das Django-Framework eine angenehme Erfahrung und wenn Sie Hilfe benötigen, lesen Sie einfach die Dokumentation.

Fehler Nr. 1: Verwenden der globalen System-Python-Umgebung für Projektabhängigkeiten

Verwenden Sie die globale Umgebung von Python nicht für Projektabhängigkeiten, da dies zu Abhängigkeitskonflikten führen kann. Python kann nicht mehrere Paketversionen gleichzeitig verwenden. Dies kann ein Problem sein, wenn verschiedene Projekte verschiedene inkompatible Versionen desselben Pakets erfordern.

Dieser Fehler wird normalerweise von neuen Python- und Django-Entwicklern gemacht, die die Umgebungsisolationsfunktionen von Python nicht kennen.

Es gibt viele Möglichkeiten, Ihre Umgebung zu isolieren, aber die gängigsten sind:

• virtualenv: Ein Python-Paket, das einen Python-Umgebungsordner generiert und Skripte zum [De]Aktivieren der Umgebung und zum Verwalten installierter Python-Pakete in der Umgebung enthält. Dies ist meine Lieblingsmethode, weil es die einfachste Art ist, die Arbeit zu erledigen. Normalerweise erstelle ich die Umgebung in der Nähe des Projektordners.
• virtualenvwrapper: Ein Python-Paket, das global installiert wird und ein Toolset zum Erstellen/Löschen/Aktivieren/usw. bereitstellt. virtuelle Umgebungen. Alle virtuellen Umgebungen werden in einem Ordner gespeichert (der durch die Umgebungsvariable WORKON_HOME überschrieben werden kann). Ich sehe keine Vorteile bei der Verwendung von virtualenvwrapper anstelle von virtualenv .
• Virtuelle Maschinen (VM): Es gibt keine größere Isolation als eine ganze virtuelle Maschine, die Ihrer Anwendung gewidmet ist. Es gibt viele Tools zur Auswahl, darunter VirtualBox (kostenlos), VMware, Parallels und Proxmox (mein persönlicher Favorit, und es gibt eine kostenlose Version). In Kombination mit einem VM-Automatisierungstool wie Vagrant kann dies eine äußerst leistungsstarke Lösung sein.
• Container: In den letzten Jahren habe ich Docker in fast jedem Projekt verwendet, insbesondere in jedem neuen Projekt, das ich von Grund auf neu beginne. Docker ist ein erstaunliches Tool, das viele Funktionen bietet und über viele Tools von Drittanbietern für die Containerautomatisierung verfügt. Es verfügt über eine Layer-Caching-Funktion, die den Wiederaufbau Ihrer Container extrem schnell macht. In Containern verwende ich die globale System-Python-Umgebung, da jeder Container sein eigenes Dateisystem hat und Projekte auf hoher Ebene isoliert sind. Docker ermöglicht es neuen Teammitgliedern, schneller mit der Arbeit am Projekt zu beginnen, insbesondere wenn sie Docker-Erfahrung haben.

Wenn Sie mich fragen, bevorzuge ich das Python-Paket virtualenv und Docker-Container für die Isolierung und Verwaltung von Projektabhängigkeiten.

Fehler Nr. 2: Projektabhängigkeiten nicht in einer requirements.txt -Datei fixieren

Jedes neue Python-Projekt sollte mit einer „requirements.txt“-Datei und einer neuen isolierten Umgebung beginnen. Normalerweise installieren Sie alle Pakete über pip/easy_install , aber vergessen Sie nie, sie auch zu Ihrer requirements.txt -Datei hinzuzufügen. Dies erleichtert ( möglicherweise angemessener) die Bereitstellung Ihres Projekts auf Servern oder für ein Teammitglied, das Projekt auf seinem eigenen Computer zu booten.

Darüber hinaus ist es genauso wichtig , die spezifische Version Ihrer Abhängigkeiten in Ihrer „ requirements.txt “-Datei anzuheften. Normalerweise stellen verschiedene Versionen eines Pakets verschiedene Module, Funktionen und Funktionsparameter bereit; Selbst eine geringfügige Versionsänderung in einer Abhängigkeit kann Ihr Paket beschädigen. Dies ist ein sehr ernstes Problem, wenn Ihr Projekt live ist und Sie regelmäßig Bereitstellungen geplant haben, da Ihr Build-System ohne Versionsverwaltung immer die neueste verfügbare Version des Pakets installiert.

Pinnen Sie Ihre Pakete immer für die Produktion! Ich persönlich verwende ein sehr nettes Tool namens pip-tools, das mir dabei hilft. Es bietet eine Reihe von Befehlszeilentools, mit denen Sie Ihre Abhängigkeiten verwalten können. Es generiert automatisch eine requirements.txt , die nicht nur Ihre Abhängigkeiten, sondern Ihren gesamten Abhängigkeitsbaum anheftet, der die Abhängigkeiten Ihrer Abhängigkeiten enthält.

Manchmal möchten Sie nur einige Pakete aus Ihrer Abhängigkeitsliste aktualisieren (z. B. nur Django/Flask/alle Frameworks oder Dienstprogramme). Wenn Sie „pip freeze“ verwendet haben, wissen Sie nicht, welche Abhängigkeiten für welche Pakete gelten, und Sie kann eine Abhängigkeit nicht aktualisieren. Mit pip-tools werden die Pakete jedoch automatisch angeheftet, je nachdem, welche Abhängigkeit Sie angeheftet haben, sodass es automatisch auflöst, welche Pakete aktualisiert werden müssen. Als Bonus wissen Sie auch genau, welches Paket aus welcher Abhängigkeit stammt, da es sie mit Kommentaren in der Datei „ requirements.txt “ markiert.

Um besonders vorsichtig zu sein, ist es eine gute Idee, auch Ihre Abhängigkeitsquelldateien zu sichern! Bewahren Sie eine Kopie in Ihrem Dateisystem, einem von Git verwalteten Ordner, einem S3-Ordner, FTP, SFTP – wo auch immer, aber haben Sie sie immer zur Hand. Es gab Fälle, in denen ein relativ kleines Paket, das nicht gelistet wurde, eine große Anzahl von Paketen auf npm beschädigte. Pip stellt hilfreicherweise das Tool zum Herunterladen aller erforderlichen Abhängigkeiten als Quelldateien bereit. Lesen Sie mehr, indem Sie pip help download .

Fehler Nr. 3: Verwenden von Python-Funktionen im alten Stil anstelle von klassenbasierten Ansichten

Manchmal ist es eine gute Idee, eine kleine Python-Funktion in der Datei views.py einer Anwendung zu verwenden, insbesondere für Tests oder Utility-Ansichten, aber im Allgemeinen sollten Sie in Ihren Anwendungen klassenbasierte Ansichten (CBVs) verwenden.

CBVs sind generische Ansichten, die abstrakte Klassen bereitstellen, die allgemeine Webentwicklungsaufgaben implementieren, die von Fachleuten erstellt wurden und alle gängigen Verhaltensweisen abdecken. Sie haben eine erstaunlich strukturierte API, und Sie können alle Vorteile der objektorientierten Programmierung nutzen, wenn Sie CBVs verwenden. Es macht Ihren Quellcode klarer und lesbarer. Vergessen Sie die Mühe, Django-Standardansichtsfunktionen für Auflistungen, CRUD-Operationen, Formularverarbeitung usw. zu verwenden. Sie erweitern einfach das geeignete CBV für Ihre Ansicht und überschreiben Klasseneigenschaften oder Funktionen (normalerweise gibt eine Funktion eine Eigenschaft zurück und Sie können dort beliebige Logik hinzufügen). macht Spaghetti aus Ihrem Quellcode, wenn Sie Ansichtsfunktionen anstelle von CBVs verwenden), die das Ansichtsverhalten konfigurieren.

Sie können beispielsweise verschiedene Mix-Ins in Ihrem Projekt haben, die grundlegende CBV-Verhalten überschreiben, um Ansichtskontexte zu erstellen, die Autorisierung auf Zeilenebene zu überprüfen, Vorlagenpfade aus Ihrer Anwendungsstruktur automatisch zu erstellen, intelligentes Caching zu integrieren und vieles mehr.

Ich habe das Paket namens Django Template Names erstellt, das Vorlagennamen für Ihre Ansichten basierend auf einem Anwendungsnamen und einem Ansichtsklassennamen standardisiert. Ich benutze es jeden Tag und es spart viel Zeit für das Erfinden von Namen. Fügen Sie einfach das Mixin in Ihr CBV ein – class Detail(TemplateNames, DetailView): – und es fängt an zu arbeiten! Natürlich können Sie meine Funktionen überschreiben und responsive Vorlagen für Mobilgeräte, verschiedene Vorlagen für Benutzeragenten oder alles andere hinzufügen, was Sie möchten.

Fehler Nr. 4: Fette Ansichten und dünne Models schreiben

Das Schreiben Ihrer Anwendungslogik in Ansichten statt in Modellen bedeutet, dass Sie Code, der in Ihr Modell gehört, in die Ansicht geschrieben haben, wodurch es „fett“ und Ihr Modell „dünn“ wird.

Du solltest fette Models, magere Ansichten schreiben.

Brechen Sie die Logik in Ihren Modellen in kleine Methoden auf. Auf diese Weise können Sie es mehrmals aus mehreren Quellen (UI der Admin-Oberfläche, Front-End-UI, API-Endpunkte, mehrere Ansichten) in wenigen Codezeilen verwenden, anstatt Tonnen von Code zu kopieren und einzufügen. Wenn Sie also das nächste Mal einem Benutzer eine E-Mail senden, erweitern Sie das Modell um eine E-Mail-Funktion, anstatt diese Logik in Ihren Controller zu schreiben.

Dies erleichtert auch den Komponententest Ihres Codes, da Sie die E-Mail-Logik an einem Ort testen können, anstatt wiederholt in jedem Controller, in dem dies stattfindet.

Sie können mehr über das Problem im Django Best Practices-Projekt lesen. Die Lösung ist einfach: Schreiben Sie fette Modelle und dünne Ansichten, also lassen Sie es uns in Ihrem nächsten Projekt tun (oder Ihr aktuelles umgestalten).

Fehler Nr. 5: Eine riesige, unüberschaubare Einstellungsdatei

Sogar die neue Django-Projekteinstellungsdatei hat viele Einstellungen. In einem echten Projekt wächst eine Einstellungsdatei auf über 700 Konfigurationszeilen an und wird schwierig zu warten sein, insbesondere wenn Ihre Entwicklungs-, Produktions- und Staging-Umgebungen alle benutzerdefinierte Konfigurationen benötigen.

Sie können die Konfigurationsdatei manuell teilen und benutzerdefinierte Ladeprogramme erstellen, aber ich möchte Ihnen ein nettes und gut getestetes Python-Paket vorstellen, Django Split Settings, das ich mitverfasst habe.

Das Paket bietet zwei Funktionen – optional und include – die Platzhalter für die Pfade unterstützen und Ihre Konfigurationsdateien im selben Kontext importieren, wodurch es einfach wird, Ihre Konfiguration mit deklarierten Konfigurationseinträgen in zuvor geladenen Dateien zu erstellen. Es wirkt sich nicht auf die Leistung von Django aus und Sie können es in jedem Projekt verwenden.

Sehen Sie sich das Beispiel für die Minimalkonfiguration an:

 from split_settings.tools import optional, include include( 'components/base.py', 'components/database.py', 'components/*.py', # the project different envs settings optional('envs/devel/*.py'), optional('envs/production/*.py'), optional('envs/staging/*.py'), # for any local settings optional('local_settings.py'), )

Fehler Nr. 6: All-in-One-Anwendung, schlechte Anwendungsstruktur und falsche Ressourcenplatzierung

Jedes Django-Projekt besteht aus mehreren Anwendungen. In Django-Notation ist eine Anwendung ein Python-Paket, das mindestens die Dateien __init__.py und models.py enthält; in den neuesten Django-Versionen wird models.py nicht mehr benötigt. __init__.py ist genug.

Django-Anwendungen können Python-Module, Django-spezifische Module (Ansichten, URLs, Modelle, Verwaltung, Formulare, Vorlagen-Tags usw.), statische Dateien, Vorlagen, Datenbankmigrationen, Verwaltungsbefehle, Einheitentests und mehr enthalten. Sie sollten Ihre monolithischen Anwendungen mit einfacher Logik in kleine, wiederverwendbare Anwendungen unterteilen. Sie sollten in der Lage sein, den gesamten Zweck der App in ein oder zwei kurzen Sätzen zu beschreiben. Zum Beispiel: „Ermöglicht Benutzern, sich zu registrieren und ihr Konto per E-Mail zu aktivieren.“

Es ist eine gute Idee, den Projektordner project zu nennen und Anwendungen in project/apps/ . Legen Sie dann alle Anwendungsabhängigkeiten in ihren eigenen Unterordnern ab.

Beispiele:

• Statische Dateien: project/apps/appname/static/appname/
• Vorlagen-Tags: project/apps/appname/templatetags/appname.py
• Vorlagendateien: project/apps/appname/templates/appname/

Stellen Sie dem Anwendungsnamen in den Unterordnern immer ein Präfix voran, da alle statischen Ordner in einem Ordner zusammengeführt werden und, wenn zwei oder mehr Anwendungen eine js/core.js -Datei hatten, die letzte Anwendung in settings.INSTALLED_APPLICATIONS die vorherigen überschreibt. Ich hatte diesen Fehler einmal in meinem aktuellen Projekt und verlor ungefähr sechs Stunden beim Debuggen, bis mir klar wurde, dass ein anderer Entwickler static/admin/js/core.js weil das Team ein benutzerdefiniertes SPA-Admin-Panel implementierte und seine Dateien auf die gleiche Weise benannte.

Hier ist eine Beispielstruktur für eine Portalanwendung mit vielen Ressourcen und Python-Modulen.

 root@c5b96c395cfb:/test# tree project/apps/portal/ project/apps/portal/ ├── __init__.py ├── admin.py ├── apps.py ├── management │ ├── __init__.py │ └── commands │ ├── __init__.py │ └── update_portal_feeds.py ├── migrations │ └── __init__.py ├── models.py ├── static │ └── portal │ ├── css │ ├── img │ └── js ├── templates │ └── portal │ └── index.html ├── templatetags │ ├── __init__.py │ └── portal.py ├── tests.py ├── urls.py └── views.py 11 directories, 14 files

Mit einer solchen Struktur können Sie die Anwendung jederzeit in ein anderes Python-Paket exportieren und erneut verwenden. Sie können es sogar in PyPi als Open-Source-Paket veröffentlichen oder in einen anderen Ordner verschieben.

Am Ende erhalten Sie eine Projektstruktur wie diese:

 root@c5b96c395cfb:/test# tree -L 3 . ├── deploy │ ├── chef │ └── docker │ ├── devel │ └── production ├── docs ├── logs ├── manage.py ├── media ├── project │ ├── __init__.py │ ├── apps │ │ ├── auth │ │ ├── blog │ │ ├── faq │ │ ├── pages │ │ ├── portal │ │ └── users │ ├── conf │ ├── settings.py │ ├── static │ ├── templates │ ├── urls.py │ └── wsgi.py └── static └── admin ├── css ├── fonts ├── img └── js 25 directories, 5 files

In einem realen Projekt wird es natürlich komplexer, aber diese Struktur macht die Dinge einfacher und sauberer.

Fehler Nr. 7: STATICFILES_DIRS und STATIC_ROOT verwirren neue Django-Entwickler

Statische Dateien sind Assets, die sich durch die Verwendung der App nicht ändern, zB JavaScript, CSS, Bilder, Schriftarten usw. In Django werden sie nur während des Deploy-Prozesses in einem öffentlichen Verzeichnis „gesammelt“.

Im Entwicklungsmodus – python manage.py runserver – sucht Django mithilfe der Einstellung STATICFILES_FINDERS nach statischen Dateien. Standardmäßig versucht es, die angeforderte statische Datei in Ordnern zu finden, die in der Einstellung STATICFILES_DIRS aufgeführt sind. Im Fehlerfall versucht Django, die Datei mit django.contrib.staticfiles.finders.AppDirectoriesFinder zu finden, das im static Ordner jeder installierten Anwendung im Projekt sucht. Dadurch können Sie wiederverwendbare Anwendungen schreiben, die mit ihren eigenen statischen Dateien ausgeliefert werden.

In der Produktion stellen Sie Ihre Statik mit einem eigenständigen Webserver wie Nginx bereit. Der Webserver weiß nichts über die Anwendungsstruktur des Django-Projekts oder darüber, in welchen Ordnern Ihre statischen Dateien verteilt sind. Glücklicherweise stellt Ihnen Django den Verwaltungsbefehl zum Sammeln statischer Dateien python manage.py collectstatic , der STATICFILES_FINDERS und alle statischen Dateien aus Anwendungen static kopiert Ordner und Ordner, die in STATICFILES_DIRS aufgeführt sind, in das Verzeichnis, das Sie in der Einstellung STATIC_ROOT angeben. Dies ermöglicht die Auflösung statischer Dateiressourcen mit derselben Logik wie der Django-Server im Entwicklungsmodus und hat alle statischen Dateien an einem Ort für Ihren Webserver.

Vergessen Sie nicht, collectstatic in Ihrer Produktionsumgebung auszuführen!

Fehler Nr. 8: Standard STATICFILES_STORAGE , Django Templates Loader in der Produktion

STATICFILES_STORAGE

Lassen Sie uns über das Asset Management der Produktionsumgebung sprechen. Wir können die beste Benutzererfahrung bieten, wenn wir eine Richtlinie „Vermögen verfallen nie“ verwenden (über die Sie hier mehr lesen können). Das bedeutet, dass alle unsere statischen Dateien wochen-, monate- oder sogar jahrelang von Webbrowsern zwischengespeichert werden sollten. Mit anderen Worten, Ihre Benutzer sollten Ihre Assets nur einmal herunterladen!

Das ist cool, und wir können es mit wenigen Zeilen in der Nginx-Konfiguration für unseren statischen Dateiordner tun, aber was ist mit der Cache-Invalidierung? Wenn der Benutzer unsere Assets nur einmal herunterlädt, was passiert, wenn Sie Ihr Logo, Schriftarten, JavaScript oder die Textfarbe für ein Element in einem Menü aktualisieren? Um dies zu umgehen, sollten Sie bei jeder Bereitstellung eindeutige URLs und Dateinamen für unsere statischen Dateien generieren!

Wir können dies einfach tun, indem wir ManifestStaticFilesStorage als STATICFILES_STORAGE (Vorsicht, Hashing ist nur im DEBUG=false -Modus aktiviert) und den oben besprochenen collectstatic -Verwaltungsbefehl ausführen. Dadurch wird die Anzahl der Asset-Anforderungen an Ihre Produktionswebsite verringert und Ihre Website wird viel schneller gerendert.

Zwischengespeicherter Django-Vorlagenlader

Eine weitere coole Django-Funktion ist der zwischengespeicherte Template-Loader, der Template-Dateien nicht bei jedem Template-Rendering neu lädt und parst. Das Analysieren von Vorlagen ist ein sehr teurer Vorgang und verbraucht viele Ressourcen. Standardmäßig werden Django-Vorlagen bei jeder Anfrage analysiert, aber das ist schlecht, besonders während der Produktion, wo Sie Tausende von Anfragen in kurzer Zeit verarbeiten können.

Sehen Sie sich den Konfigurationsabschnitt cached.Loader an, um ein gutes Beispiel und Details dazu zu erhalten. Verwenden Sie den Loader nicht im Entwicklungsmodus, da er geparste Vorlagen nicht aus dem Dateisystem neu lädt; Sie müssen Ihr Projekt bei jeder Vorlagenänderung mit python manage.py startapp neu starten. Das kann während der Entwicklung ärgerlich sein, ist aber perfekt für die Produktionsumgebung.

Fehler Nr. 9: Reine Python-Skripte für Utilities oder Skripte

Django bietet eine sehr nette Funktion namens Management Commands. Verwenden Sie es einfach, anstatt Räder neu zu erfinden und rohe Python-Skripte für Ihre Projektdienstprogramme zu schreiben.

Sehen Sie sich auch das Django Extensions-Paket an, bei dem es sich um eine Sammlung benutzerdefinierter Erweiterungen für Django handelt. Vielleicht hat jemand Ihre Befehle bereits implementiert! Es gibt bereits viele allgemeine Aufgabenbefehle.

Fehler Nr. 10: Das Rad neu erfinden

Django und Python haben Tausende von gebrauchsfertigen Lösungen. Versuchen Sie zu googeln, bevor Sie etwas schreiben, das nicht einzigartig ist; Wahrscheinlich gibt es bereits eine funktionsreiche Lösung.

Versuchen Sie einfach, die Dinge einfach zu machen. Erst googlen! Installieren, konfigurieren, erweitern und integrieren Sie es in Ihr Projekt, wenn Sie ein qualitativ hochwertiges Paket finden, und tragen Sie natürlich zu Open Source bei, wenn Sie die Möglichkeit dazu haben.

Hier ist zunächst eine Liste meiner eigenen öffentlichen Pakete für Django:

• Django Macros URL erleichtert das Schreiben (und Lesen) von URL-Mustern in Ihren Django-Anwendungen mithilfe von Makros.
• Django Templates Names ist ein kleines Mix-In, mit dem Sie Ihre CBV-Vorlagennamen einfach standardisieren können.
• Mit django-split-settings können Sie Django-Einstellungen in mehreren Dateien und Verzeichnissen organisieren. Einfaches Überschreiben und Ändern von Einstellungen. Verwenden Sie Platzhalter in den Pfaden der Einstellungsdateien und markieren Sie die Einstellungsdateien als optional.

Wiederholen Sie sich nicht (DRY)!

Ich mag die DRY-Methodik sehr; Aus diesem Grund habe ich Django Skeleton als praktisches Tool erstellt, das einige wirklich nette Funktionen bietet:

• Docker-Images für Entwicklung/Produktion, verwaltet von docker-compose, mit denen Sie eine Liste von Containern einfach orchestrieren können.
• Einfaches Fabric-Skript für die Bereitstellung in der Produktion.
• Konfiguration für das Django Split Settings-Paket mit Einstellungen für Basis- und lokale Quellen.
• In das Projekt integriertes Webpack - Nur der dist -Ordner wird von Django auf den Befehl collectstatic gesammelt.
• Konfigurierte alle grundlegenden Django-Einstellungen und -Funktionen wie zwischenspeicherbare Django-Vorlagen in der Produktion, gehashte statische Dateien, integrierte Debug-Symbolleiste, Protokollierung usw.

Es ist ein gebrauchsfertiges Django-Skelett für Ihr nächstes Projekt von Grund auf neu und wird Ihnen hoffentlich viel Zeit sparen, indem Sie Ihr Projekt booten. Webpack hat eine minimale Grundkonfiguration, aber es hat auch SASS installiert, das vorkonfiguriert ist, um .scss -Dateien zu verarbeiten.