Forbedre dit Django-projekt med disse bedste praksis

Django er en robust, open source, Python-baseret ramme til opbygning af webapplikationer. Dens popularitet er steget i løbet af de sidste par år, og det er allerede modent og udbredt med et stort samfund bag sig.

Blandt andre Python-baserede rammer til oprettelse af webapplikationer (som Flask og Pyramid) er Django langt den mest populære. Det understøtter både Python version 2.7 og Python 3.6. Men på tidspunktet for denne artikel er Python 2.7 stadig den mere tilgængelige version med hensyn til fællesskab, tredjepartspakker og online dokumentation. Django er sikker, når den bruges korrekt og giver høje dimensioner af fleksibilitet. Det er vejen at gå, når man udvikler applikationer på serversiden ved hjælp af Python.

Som en erfaren Python- og Django-udvikler deler jeg nogle af de bedste fremgangsmåder til en Django-opsætning, som jeg har lært og samlet gennem årene. Uanset om du har et par Django-projekter under hånden, eller du lige er ved at starte din første fra bunden, kan de bedste fremgangsmåder, der er beskrevet her, hjælpe dig med at oprette bedre applikationer nede.

Jeg skrev denne artikel ud fra en meget praktisk tankegang, så du straks kan tilføje nogle værktøjer til din udviklingsværktøjskasse. Du kan endda oprette en avanceret brugerdefineret Django kedelplade til dine næste projekter.

Med henblik på denne artikel antager jeg, at du bruger en Linux Ubuntu-maskine. I hele artiklen starter nogle kodelinjer med et $tegn. Disse bruges til at understrege, at denne linje skal indsættes i terminalen. Sørg for at kopiere linien uden at $skiltet.

Virtuelt miljø

Mens du udvikler Python-baserede applikationer, er det en løbende ting at bruge tredjepartspakker. Disse pakker opdateres ofte, så det er vigtigt at holde dem organiseret. Når du udvikler flere og flere projekter på den samme lokale maskine, er det udfordrende at holde styr på den aktuelle version af hver pakke. Det er umuligt at bruge forskellige versioner af den samme pakke til forskellige projekter. Desuden kan opdatering af en pakke på et projekt muligvis bryde funktionaliteten på et andet og omvendt.

Det er her, Python Virtual Environment er praktisk. Sådan installeres brug af virtuelt miljø:

$ apt-get update $ apt-get install python-pip python-dev build-essential $ export LC_ALL="en_US.UTF-8" # might be necessary in case you get an error from the next line $ pip install --upgrade pip $ pip install --upgrade virtualenv $ mkdir ~/.virtualenvs $ pip install virtualenvwrapper $ export WORKON_HOME=~/.virtualenvs $ nano ~/.bashrc

Tilføj denne linje til slutningen af ​​filen:

. /usr/local/bin/virtualenvwrapper.sh

Udfør derefter:

$ . .bashrc

Efter installation skal du oprette et nyt virtuelt miljø til dit projekt ved at skrive:

$ mkvirtualenv project_name

Mens du er i sammenhæng med dit virtuelle miljø, vil du bemærke, at der føjes et præfiks til terminalen, som:

(project_name) [email protected]:~$

For at deaktivere (afslutte) det virtuelle miljø og komme tilbage til den primære Python-kontekst på din lokale maskine, skal du bruge:

$ deactivate

For at aktivere (starte) den virtuelle miljøkontekst skal du bruge:

$ workon project_name

For at liste de virtuelle miljøer, der findes på din lokale maskine, skal du bruge:

$ lsvirtualenv

Hvis du holder dine projektafhængigheder (pakker) i et virtuelt miljø på din maskine, kan du holde dem i et isoleret miljø. Du bruger dem kun til et enkelt (eller flere) projekter. Når du opretter et nyt virtuelt miljø, starter du et nyt miljø uden pakker installeret i det. Derefter kan du f.eks. Bruge:

(project_name) $ pip install Django

til installation af Django i dit virtuelle miljø, eller:

(project_name) $ pip install Django==1.11

til installation af version 1.11 af Django, der kun er tilgængelig fra miljøet.

Hverken din primære Python-tolk eller de andre virtuelle miljøer på din maskine kan få adgang til den nye Django-pakke, du lige har installeret.

For at bruge kommandoen runserver ved hjælp af dit virtuelle miljø, mens du er i sammenhæng med det virtuelle miljø, skal du bruge:

(project_name) $ cd /path/to/django/project (project_name) $ ./manage.py runserver

Når du går ind i Python-tolk fra det virtuelle miljø, skal du også skrive:

(project_name) $ python

Det har adgang til pakker, du allerede har installeret i miljøet.

Krav

Krav er listen over Python-pakker (afhængigheder), dit projekt bruger, mens det kører, inklusive versionen for hver pakke. Her er et eksempel på en requirements.txtfil:

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 six==1.10.0 xmltodict==0.11.0

Det requirements.txter vigtigt at holde din fil opdateret for at samarbejde korrekt med andre udviklere. Det er også vigtigt for at holde dit produktionsmiljø korrekt konfigureret. Denne fil, når den er inkluderet i dit kodelager, giver dig mulighed for at opdatere alle de pakker, der er installeret i dit virtuelle miljø, ved at udføre en enkelt linje i terminalen. Derefter kan du få nye udviklere i gang på ingen tid.

For at generere en ny requirements.txteller opdatere en eksisterende skal du bruge inden i dit virtuelle miljø:

(project_name) $ pip freeze > requirements.txt

For din bekvemmelighed skal du sørge for at udføre denne kommando i en mappe, der spores af dit Git-arkiv. Dette giver også andre forekomster af koden adgang til requirements.txtfilen.

Hvis en ny udvikler slutter sig til teamet, eller hvis du vil konfigurere et nyt miljø ved hjælp af de samme pakker, der er angivet i requirements.txtfilen, skal du udføre i den virtuelle miljøkontekst:

(project_name) $ cd /path/to/requirements/file (project_name) $ pip install -r requirements.txt

Alle krav, der er anført i filen, installeres straks i dit virtuelle miljø. Ældre versioner opdateres, og nyere versioner nedgraderes, så de passer til den nøjagtige liste over requirements.txt. Vær dog forsigtig - der kan være forskelle mellem miljøer, som du stadig vil respektere.

I highly recommend integrating these commands to your work flow. Update the requirements.txt file before pushing code to the repository and install requirements.txt file after pulling code from the repository.

Better settings.py configuration

Django comes out-of-the-box with a very basic yet useful settings.py file. This defines the main and most useful configurations for your project. The settings.py file is very straightforward. But sometimes, as a developer working on a team, or when setting up a production environment, you need more than one basic settings.py file.

Multiple settings files allow you to easily define tailor-made configurations for each environment separately like:

ALLOWED_HOSTS # for production environment DEBUG DATABASES # for different developers on the same team

Let me introduce you to an extended approach for configuring your settings.py file. It allows you to maintain different versions and use the one you want at any given time and in any environment.

First, navigate to your settings.py file path:

(project_name) $ cd /path/to/settings/file

Then create a new module called settings (module is a folder containing an __init__.py file):

(project_name) $ mkdir settings

Now, rename your settings.py file to base.py and place it inside the new module you created:

(project_name) $ mv settings.py settings/base.py

For this example, I assume that you want to configure one settings file for your development environment and one for your production environment. Different developers on the same team can use the exact same approach for defining different settings files.

For your development environment create:

(project_name) $ nano settings/development.py

Then type:

from .base import * DEBUG = True

and save the file by hitting Ctrl + O, Enter and then Ctrl + X.

For your production environment create:

(project_name) $ nano settings/production.py

and type:

from .base import * DEBUG = False ALLOWED_HOSTS = [‘app.project_name.com’, ]

Now, whenever you want to add or update the settings of a specific environment, you can easily do it in its own settings file.

You might be wondering — how does Django know which settings file to load on each environment? That’s what the __init__.py file is used for. When Django looks for the settings.py it used to load when running the server, for example, it now finds a settings module rather than a settings.py file. But as long as it’s a module containing an __init__.py file, as far as Django is concerned, it’s the exact same thing. Django will load the __init__.py file and execute whatever is written in it.

Therefore, we need to define which settings file we want to load inside the __init__.py file by executing:

(project_name) $ settings/__init__.py

and then, for a production environment, for example, by typing:

from .production import *

This way, Django will load all the base.py and production.py settings every time it starts. Magic?

Now, the only configuration left is to keep the __init__.py in your .gitignore file so it will not be included in pushes and pulls. Once you set up a new environment, don’t forget to create a new __init__.py file inside the settings module. Then import the settings file required exactly like we did before.

In this article we’ve covered three best practices for better setting up your Django project:

  • Working inside a virtual environment
  • Keeping the requirements.txt file up to date and using it continuously in your work flow
  • Setting up a better project settings array

Have you followed these best practices in your last project? Do you have any insights to share? Comments are highly appreciated.

Fandt du dette nyttigt? Giv mig i så fald nogle klapper, så flere mennesker ser artiklen.

Dette er del 1 i serien om bedste praksis for Django-udvikling. Følg mig for at få en øjeblikkelig opdatering, når de næste dele er tilgængelige.

Find flere gode tip til teknologiske iværksættere på CodingStartups.