Poboljšajte svoj Django projekt pomoću ovih najboljih praksi

Programiranje

Django je robustan, open-source, Python-based okvir za izgradnju web aplikacija. Njegova se popularnost povećala tijekom posljednjih nekoliko godina, a već je zreo i široko se koristi s velikom zajednicom iza sebe.

Među ostalim okvirima koji se temelje na Pythonu za stvaranje web aplikacija (poput Flaska i Pyramida), Django je daleko najpopularniji. Podržava i Python verziju 2.7 i Python 3.6. Ali u vrijeme ovog članka, Python 2.7 je još uvijek pristupačnija verzija u pogledu zajednice, paketa treće strane i mrežne dokumentacije. Django je siguran kada se pravilno koristi i pruža velike dimenzije fleksibilnosti. To je put kojim se ide prilikom razvijanja aplikacija na poslužitelju pomoću Pythona.

Kao iskusni programer za Python i Django, podijelit ću s vama neke najbolje prakse za postavljanje Djanga koje sam naučio i prikupio tijekom godina. Bez obzira imate li nekoliko Django projekata ili ćete tek započeti svoj prvi od početka, najbolji ovdje opisani postupci mogli bi vam pomoći u stvaranju boljih aplikacija.

Ovaj sam članak napisao iz vrlo praktičnog načina razmišljanja tako da možete odmah dodati neke alate u svoj razvojni alat. Možete čak stvoriti napredni prilagođeni obrazac Django za svoje sljedeće projekte.

U svrhu ovog članka pretpostavljam da koristite Linux Ubuntu stroj. Kroz članak, neke retke koda započinju $znakom. Pomoću njih se naglašava da bi ovu liniju trebalo umetnuti u terminal. Svakako kopirajte liniju bez na $znaku.

Virtualno okruženje

Dok razvijamo aplikacije temeljene na Pythonu, upotreba paketa trećih strana neprestana je stvar. Ovi se paketi često ažuriraju, pa je njihovo održavanje izuzetno bitno. Kada razvijate sve više i više projekata na istom lokalnom stroju, izazovno je pratiti trenutnu verziju svakog paketa. Nemoguće je koristiti različite verzije istog paketa za različite projekte. Štoviše, ažuriranje paketa na jednom projektu može pokvariti funkcionalnost drugog, i obrnuto.

Tu Python virtualno okruženje dobro dolazi. Da biste instalirali virtualno okruženje:

$ 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

Dodajte ovaj redak na kraj datoteke:

. /usr/local/bin/virtualenvwrapper.sh

Zatim izvršite:

$ . .bashrc

Nakon instalacije stvorite novo virtualno okruženje za svoj projekt upisivanjem:

$ mkvirtualenv project_name

Dok ste u kontekstu svog virtualnog okruženja, primijetit ćete da se terminalu dodaje prefiks, poput:

(project_name) [email protected]:~$

Da biste deaktivirali (izašli) iz virtualnog okruženja i vratili se u glavni Python kontekst vašeg lokalnog računala, upotrijebite:

$ deactivate

Da biste aktivirali (pokrenuli) kontekst virtualnog okruženja, upotrijebite:

$ workon project_name

Da biste popisali virtualna okruženja koja postoje na vašem lokalnom računalu, upotrijebite:

$ lsvirtualenv

Držanje ovisnosti o projektu (paketa) u virtualnom okruženju na vašem stroju omogućuje vam zadržavanje u izoliranom okruženju. Koristite ih samo za jedan (ili više) projekata. Prilikom stvaranja novog virtualnog okruženja započinjete novo okruženje bez instaliranih paketa. Tada možete koristiti, na primjer:

(project_name) $ pip install Django

za instaliranje Djanga u vaše virtualno okruženje ili:

(project_name) $ pip install Django==1.11

za instaliranje verzije 1.11 Djanga dostupne samo iz okoline.

Ni vaš glavni Python tumač ni ostala virtualna okruženja na vašem računalu neće moći pristupiti novom paketu Django koji ste upravo instalirali.

Da biste koristili naredbu runserver koristeći vaše virtualno okruženje, dok ste u kontekstu virtualnog okruženja, upotrijebite:

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

Isto tako, prilikom ulaska u Python interpreter iz virtualnog okruženja, upišite:

(project_name) $ python

Imat će pristup paketima koje ste već instalirali u okruženju.

Zahtjevi

Zahtjevi su popis Python paketa (ovisnosti) koje vaš projekt koristi dok se izvodi, uključujući verziju svakog paketa. Evo primjera za requirements.txtdatoteku:

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

Ažuriranje requirements.txtdatoteke bitno je za pravilnu suradnju s drugim programerima. Također je važno za održavanje pravilno konfiguriranog proizvodnog okruženja. Ova datoteka, kad je uključena u vaše spremište koda, omogućuje vam ažuriranje svih paketa instaliranih u vašem virtualnom okruženju izvršavanjem jednog retka u terminalu. Tada možete u kratkom vremenu pokrenuti i pokrenuti nove programere.

Da biste generirali novi requirements.txtili ažurirali postojeći, koristite iz svog virtualnog okruženja:

(project_name) $ pip freeze > requirements.txt

Radi vaše udobnosti, pobrinite se da izvršite ovu naredbu u mapi koju prati vaše Git spremište. To omogućuje da i druge instance koda imaju pristup requirements.txtdatoteci.

Ako se timu pridruži novi programer ili ako želite konfigurirati novo okruženje koristeći iste pakete navedene u requirements.txtdatoteci, izvršite u kontekstu virtualnog okruženja:

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

Svi zahtjevi navedeni u datoteci odmah će se instalirati u vaše virtualno okruženje. Starije verzije bit će ažurirane, a novije verzije degradirane kako bi odgovarale točnom popisu requirements.txt. Ipak, budite oprezni - možda postoje razlike između okolina koje i dalje želite poštivati.

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.

Did you find this useful? If so, please give me some claps so more people see the article.

This is part 1 in the series about best practices for Django development. Follow me to get an immediate update once the next parts are available.

Find more great tips for technological entrepreneurs at CodingStartups.