Verbeter uw Django-project met deze best practices

Django is een robuust, open-source, op Python gebaseerd framework voor het bouwen van webapplicaties. De populariteit is de afgelopen jaren toegenomen en het is al volwassen en wordt veel gebruikt met een grote gemeenschap erachter.

Naast andere op Python gebaseerde frameworks voor het maken van webapplicaties (zoals Flask en Pyramid), is Django veruit de meest populaire. Het ondersteunt zowel Python versie 2.7 als Python 3.6. Maar op het moment van dit artikel is Python 2.7 nog steeds de meer toegankelijke versie op het gebied van community, pakketten van derden en online documentatie. Django is veilig bij correct gebruik en biedt hoge dimensies van flexibiliteit. Het is dé manier om server-side applicaties te ontwikkelen met behulp van Python.

Google Trends van de 3 populairste Python-webontwikkelingskaders

Als ervaren Python- en Django-ontwikkelaar zal ik enkele best practices met u delen voor een Django-opstelling die ik door de jaren heen heb geleerd en verzameld. Of u nu een paar Django-projecten onder uw riem heeft, of u gaat net met uw eerste beginnen, de best practices die hier worden beschreven, kunnen u helpen om onderweg betere toepassingen te maken.

Ik heb dit artikel geschreven vanuit een zeer praktische manier van denken, zodat je meteen wat tools aan je ontwikkelingstoolbox kunt toevoegen. U kunt zelfs een geavanceerde aangepaste Django-boilerplate maken voor uw volgende projecten.

Voor het doel van dit artikel ga ik ervan uit dat je een Linux Ubuntu-machine gebruikt. In het hele artikel beginnen sommige coderegels met een $ -teken. Deze worden gebruikt om te benadrukken dat deze lijn in de terminal moet worden ingevoegd. Zorg ervoor dat u de regel zonder het $ -teken kopieert.

Virtuele omgeving

Bij het ontwikkelen van op Python gebaseerde applicaties is het gebruik van pakketten van derden een doorlopend iets. Deze pakketten worden vaak bijgewerkt, dus het is essentieel om ze georganiseerd te houden. Wanneer u meer en meer projecten op dezelfde lokale machine ontwikkelt, is het een uitdaging om de huidige versie van elk pakket bij te houden. Het is onmogelijk om verschillende versies van hetzelfde pakket te gebruiken voor verschillende projecten. Bovendien kan het bijwerken van een pakket in het ene project de functionaliteit op een ander project breken en vice versa.

Dat is waar Python Virtual Environment van pas komt. Gebruik de virtuele omgeving om:

$ apt-get update
$ apt-get install python-pip python-dev build-essential
$ export LC_ALL = "en_US.UTF-8" # kan nodig zijn voor het geval u een foutmelding krijgt van de volgende regel
$ pip install - upgrade pip
$ pip install --upgrade virtualenv
$ mkdir ~ / .virtualenvs
$ pip install virtualenvwrapper
$ export WORKON_HOME = ~ / .virtualenvs
$ nano ~ / .bashrc

Voeg deze regel toe aan het einde van het bestand:

. /usr/local/bin/virtualenvwrapper.sh

Voer vervolgens uit:

$. .bashrc

Maak na installatie een nieuwe virtuele omgeving voor uw project door te typen:

$ mkvirtualenv projectnaam

Terwijl u zich in de context van uw virtuele omgeving bevindt, zult u merken dat een voorvoegsel aan de terminal is toegevoegd, zoals:

(projectnaam) ofir @ playground: ~ $

Om de virtuele omgeving te deactiveren (te verlaten) en terug te keren naar de belangrijkste Python-context van uw lokale machine, gebruikt u:

$ deactiveren

Om de context van de virtuele omgeving te activeren (starten), gebruikt u:

$ workon projectnaam

Om de virtuele omgevingen in uw lokale machine te vermelden, gebruikt u:

$ lsvirtualenv

Door uw projectafhankelijkheden (pakketten) in een virtuele omgeving op uw machine te houden, kunt u ze in een geïsoleerde omgeving houden. Je gebruikt ze alleen voor een (of meerdere) projecten. Wanneer u een nieuwe virtuele omgeving maakt, start u een nieuwe omgeving zonder dat er pakketten in zijn geïnstalleerd. Dan kunt u bijvoorbeeld gebruiken:

(project_name) $ pip install Django

voor het installeren van Django in uw virtuele omgeving, of:

(projectnaam) $ pip install Django == 1.11

voor het installeren van versie 1.11 van Django die alleen toegankelijk is vanuit de omgeving.

Noch uw belangrijkste Python-tolk noch de andere virtuele omgevingen op uw machine hebben toegang tot het nieuwe Django-pakket dat u zojuist hebt geïnstalleerd.

Om de opdracht runerver te gebruiken met behulp van uw virtuele omgeving, gebruikt u in de context van de virtuele omgeving:

(projectnaam) $ cd / pad / naar / django / project
(projectnaam) $ ./manage.py runserver

Wanneer u de Python-interpreter vanuit de virtuele omgeving betreedt, typt u ook:

(projectnaam) $ python

Het heeft toegang tot pakketten die u al in de omgeving heeft geïnstalleerd.

Voorwaarden

Vereisten zijn de lijst met Python-pakketten (afhankelijkheden) die uw project gebruikt terwijl het wordt uitgevoerd, inclusief de versie voor elk pakket. Hier is een voorbeeld voor een requirements.txt-bestand:

dicttoxml == 1.7.4
Django == 1.11.2
h5py == 2.7.0
matplotlib == 2.0.2
numpy == 1.13.0
Pillow == 4.1.1
psycopg2 == 2.7.1
pyparsing == 2.2.0
python-dateutil == 2.6.0
pytz == 2017,2
zes == 1.10.0
xmltodict == 0.11.0

Het up-to-date houden van uw requirements.txt-bestand is essentieel voor een goede samenwerking met andere ontwikkelaars. Het is ook belangrijk om uw productieomgeving goed geconfigureerd te houden. Wanneer dit bestand in uw coderepository is opgenomen, kunt u alle pakketten die in uw virtuele omgeving zijn geïnstalleerd bijwerken door een enkele regel in de terminal uit te voeren. Dan kunt u in een mum van tijd nieuwe ontwikkelaars in gebruik nemen.

Om vanuit uw virtuele omgeving een nieuw requirements.txt te genereren of een bestaande bij te werken:

(projectnaam) $ pip freeze> requirements.txt

Voer voor uw gemak deze opdracht uit in een map die wordt gevolgd door uw Git-repository. Hierdoor hebben andere instanties van de code ook toegang tot het bestand requirements.txt.

Als een nieuwe ontwikkelaar lid wordt van het team of als u een nieuwe omgeving wilt configureren met dezelfde pakketten die worden vermeld in het bestand requirements.txt, voer dan uit in de context van de virtuele omgeving:

(projectnaam) $ cd / pad / naar / vereisten / bestand
(project_name) $ pip install -r requirements.txt

Alle vereisten in het bestand worden onmiddellijk geïnstalleerd in uw virtuele omgeving. Oudere versies worden bijgewerkt en nieuwere versies worden gedowngraded zodat ze exact in de lijst met requirements.txt passen. Wees echter voorzichtig - er kunnen verschillen zijn tussen omgevingen die u nog steeds wilt respecteren.

Ik raad ten zeerste aan om deze opdrachten in uw workflow te integreren. Werk het requirements.txt-bestand bij voordat u code naar de repository pusht en installeer het requirements.txt-bestand nadat u code uit de repository hebt gehaald.

Credit: https://www.djangoproject.com/

Betere instellingen.py-configuratie

Django komt out-of-the-box met een zeer eenvoudig maar handig bestand settings.py. Dit definieert de belangrijkste en meest bruikbare configuraties voor uw project. Het bestand settings.py is heel eenvoudig. Maar soms, als ontwikkelaar die in een team werkt, of bij het opzetten van een productieomgeving, hebt u meer dan één elementair instellingen.py-bestand nodig.

Met meerdere instellingenbestanden kunt u eenvoudig op maat gemaakte configuraties voor elke omgeving afzonderlijk definiëren, zoals:

ALLOWED_HOSTS # voor productieomgeving
DEBUG
DATABASES # voor verschillende ontwikkelaars in hetzelfde team

Laat me je voorstellen aan een uitgebreide aanpak voor het configureren van je instellingen.py-bestand. Hiermee kunt u verschillende versies op elk gewenst moment en in elke omgeving gebruiken en gebruiken.

Navigeer eerst naar het bestandspad settings.py:

(projectnaam) $ cd / pad / naar / instellingen / bestand

Maak vervolgens een nieuwe module met de naam instellingen (module is een map met een __init__.py-bestand):

(projectnaam) $ mkdir instellingen

Wijzig nu de naam van uw instellingen.py-bestand in base.py en plaats het in de nieuwe module die u hebt gemaakt:

(projectnaam) $ mv settings.py instellingen / base.py

In dit voorbeeld ga ik ervan uit dat u één instellingenbestand voor uw ontwikkelomgeving en één voor uw productieomgeving wilt configureren. Verschillende ontwikkelaars in hetzelfde team kunnen exact dezelfde aanpak gebruiken voor het definiëren van verschillende instellingenbestanden.

Maak voor uw ontwikkelomgeving:

(project_name) $ nano settings / development.py

Typ vervolgens:

van .base import *
DEBUG = waar

en sla het bestand op door Ctrl + O, Enter en vervolgens Ctrl + X te raken.

Maak voor uw productieomgeving:

(project_name) $ nano settings / production.py

en typ:

van .base import *
DEBUG = Niet waar
ALLOWED_HOSTS = [‘app.project_name.com’,]

Wanneer u nu de instellingen van een specifieke omgeving wilt toevoegen of bijwerken, kunt u dit eenvoudig doen in het eigen instellingenbestand.

Je vraagt ​​je misschien af ​​- hoe weet Django welk instellingenbestand in elke omgeving moet worden geladen? Daar wordt het __init__.py-bestand voor gebruikt. Wanneer Django bijvoorbeeld naar de instellingen.py zoekt die het laadde bij het uitvoeren van de server, vindt het nu een instellingenmodule in plaats van een bestand instellingen.py. Maar zolang het een module is die een __init__.py-bestand bevat, is het voor Django precies hetzelfde. Django laadt het __init__.py-bestand en voert alles uit wat erin staat.

Daarom moeten we definiëren welk instellingenbestand we in het __init__.py-bestand willen laden door het volgende uit te voeren:

(projectnaam) $ settings / __ init__.py

en vervolgens, voor een productieomgeving, bijvoorbeeld door te typen:

van .productie import *

Op deze manier laadt Django alle base.py- en production.py-instellingen telkens wanneer deze wordt gestart. Magie?

Nu is de enige configuratie die overblijft om __init__.py in uw .gitignore-bestand te houden, zodat het niet wordt opgenomen in pushen en pulls. Vergeet niet om een ​​nieuw __init__.py-bestand te maken in de instellingenmodule nadat u een nieuwe omgeving heeft ingesteld. Importeer vervolgens het vereiste instellingenbestand precies zoals eerder.

In dit artikel hebben we drie best practices besproken voor het beter opzetten van uw Django-project:

  • Werken in een virtuele omgeving
  • Het requirements.txt-bestand up-to-date houden en continu gebruiken in uw workflow
  • Een betere array met projectinstellingen instellen

Heb je deze best practices in je laatste project gevolgd? Heeft u inzichten om te delen? Reacties worden zeer op prijs gesteld.

Vond u dit nuttig? Als dat zo is, geef me dan wat klappen zodat meer mensen het artikel zien.

Dit is deel 1 in de serie over best practices voor de ontwikkeling van Django. Volg mij om direct een update te krijgen zodra de volgende onderdelen beschikbaar zijn.

Vind meer geweldige tips voor technologische ondernemers op CodingStartups.