Fejlessze Django projektjét ezekkel a bevált módszerekkel

A Django egy robusztus, nyílt forráskódú, Python-alapú keretrendszer webalkalmazások felépítésére. Népszerűsége az elmúlt néhány évben nőtt, és már kiforrott és széles körben elterjedt, nagy közösség mögött.

A webalkalmazások létrehozására szolgáló egyéb Python-alapú keretrendszerek (például a lombik és a piramis) mellett a Django messze a legnépszerűbb. Támogatja a Python 2.7 és a Python 3.6 verziókat is. De a cikk készítésekor a Python 2.7 még mindig a hozzáférhetőbb verzió a közösségi, harmadik féltől származó csomagok és az online dokumentáció tekintetében. A Django megfelelő használat esetén biztonságos, és nagy rugalmasságot biztosít. Ez a helyes út a szerveroldali alkalmazások Python használatával történő fejlesztésekor.

Tapasztalt Python és Django fejlesztőként megosztok veletek néhány bevált gyakorlatot a Django telepítéséhez, amelyeket az évek során megtanultam és összegyűjtöttem. Akár néhány Django-projekt van az öv alatt, vagy éppen az elsőt kezdi a semmiből, az itt leírt bevált gyakorlatok segíthetnek jobb alkalmazások létrehozásában az úton.

Ezt a cikket nagyon praktikus gondolkodásmódból írtam, hogy azonnal hozzáadhasson néhány eszközt a fejlesztési eszköztárához. Még egy speciális Django kazánt is létrehozhat a következő projektjeihez.

E cikk alkalmazásában feltételezem, hogy Linux Ubuntu gépet használ. A cikkben néhány kódsor $előjellel kezdődik . Ezekkel hangsúlyozzuk, hogy ezt a sort be kell illeszteni a terminálba. Győződjön meg róla, hogy másolja a vonal nélkül a $jel.

Virtuális környezet

A Python-alapú alkalmazások fejlesztése közben a harmadik féltől származó csomagok használata folyamatos dolog. Ezeket a csomagokat gyakran frissítik, ezért szervezetten kell tartani őket. Ha egyre több projektet fejleszt ki ugyanazon a helyi gépen, kihívást jelent az egyes csomagok aktuális verziójának nyomon követése. Lehetetlen ugyanazon csomag különböző verzióit használni különböző projektekhez. Ezenkívül az egyik projekt csomagjának frissítése megsértheti a másik funkcionalitását, és fordítva.

Itt jön a Python virtuális környezet. A virtuális környezet telepítéséhez használja:

$ 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

Adja hozzá ezt a sort a fájl végéhez:

. /usr/local/bin/virtualenvwrapper.sh

Ezután hajtsa végre:

$ . .bashrc

A telepítés után hozzon létre egy új virtuális környezetet a projektjéhez a következő beírásával:

$ mkvirtualenv project_name

Amíg a virtuális környezetében van, észreveszi, hogy a terminálhoz előtagot adnak, például:

(project_name) [email protected]:~$

A virtuális környezet inaktiválásához (kilépéshez) és a helyi gép fő Python-kontextusához való visszatéréshez használja:

$ deactivate

A virtuális környezet kontextusának aktiválásához (indításához) használja:

$ workon project_name

A helyi számítógépen létező virtuális környezetek felsorolásához használja:

$ lsvirtualenv

Ha projektfüggőségeit (csomagjait) virtuális környezetben tartja a gépén, akkor elszigetelt környezetben tarthatja őket. Csak egyetlen (vagy több) projekthez használhatja őket. Új virtuális környezet létrehozásakor új környezetet indít, amelyben nincsenek csomagok telepítve. Ezután használhatja például:

(project_name) $ pip install Django

a Django virtuális környezetbe történő telepítéséhez, vagy:

(project_name) $ pip install Django==1.11

a Django 1.11 verziójának telepítéséhez, amely csak a környezetből érhető el.

Sem a fő Python-tolmács, sem a gép többi virtuális környezete nem lesz képes hozzáférni az imént telepített új Django-csomaghoz.

A runerver parancs használatához a virtuális környezet használatával használja a következőt:

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

Hasonlóképpen, amikor a Python-tolmácsot a virtuális környezetből írja be, írja be:

(project_name) $ python

Hozzáférhet azokhoz a csomagokhoz, amelyeket már telepített a környezetbe.

Követelmények

A követelmények azok a Python-csomagok (függőségek) listája, amelyeket a projekt futás közben használ, beleértve az egyes csomagok verzióit is. Íme egy példa egy requirements.txtfájlra:

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 requirements.txtfájl naprakészen tartása elengedhetetlen a megfelelő együttműködéshez más fejlesztőkkel. Ez fontos a termelési környezet megfelelő konfigurálásához is. Ez a fájl, ha a kódtárában szerepel, lehetővé teszi a virtuális környezetbe telepített összes csomag frissítését egyetlen terminál végrehajtásával. Ezután pillanatok alatt beindíthatja az új fejlesztőket.

Új létrehozásához requirements.txtvagy egy meglévő frissítéséhez használja a virtuális környezetből:

(project_name) $ pip freeze > requirements.txt

Az Ön kényelme érdekében ne felejtse el végrehajtani ezt a parancsot egy olyan mappában, amelyet a Git-tárház követ. Ez lehetővé teszi, hogy a kód más példányai is hozzáférjenek a requirements.txtfájlhoz.

Ha új fejlesztő csatlakozik a csapathoz, vagy ha egy új környezetet szeretne konfigurálni a requirements.txtfájlban felsorolt ​​ugyanazokkal a csomagokkal , hajtsa végre a virtuális környezetben:

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

A fájlban felsorolt ​​összes követelmény azonnal telepítésre kerül a virtuális környezetben. A régebbi verziókat frissítjük, és az újabb verziókat le fogjuk cserélni, hogy megfeleljenek a pontos listának requirements.txt. Legyen óvatos - lehetnek olyan különbségek a környezetek között, amelyeket továbbra is tiszteletben akar tartani.

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.