これらのベスト プラクティスを使用して Django プロジェクトを改善します

オフィール・チャコン著

Django は、Web アプリケーションを構築するための堅牢なオープンソースの Python ベースのフレームワークです。その人気はここ数年で高まっており、すでに成熟しており、大規模なコミュニティを背景に広く使用されています。

Web アプリケーションを作成するための Python ベースのフレームワーク (Flask や Pyramid など) の中で、Django が最も人気があります。 Python バージョン 2.7 と Python 3.6 の両方をサポートします。ただし、この記事の執筆時点では、コミュニティ、サードパーティのパッケージ、オンライン ドキュメントの点で Python 2.7 がまだアクセスしやすいバージョンです。 Django は、適切に使用すれば安全であり、高い柔軟性を提供します。これは、Python を使用してサーバーサイド アプリケーションを開発する場合の方法です。

経験豊富な Python および Django 開発者として、私が長年にわたって学び収集してきた Django セットアップのベスト プラクティスをいくつか共有します。いくつかの Django プロジェクトを抱えている場合でも、最初のプロジェクトをゼロから始めようとしている場合でも、ここで説明するベスト プラクティスは、将来的により良いアプリケーションを作成するのに役立つ可能性があります。

この記事は、開発ツールボックスにいくつかのツールをすぐに追加できるように、非常に実践的な考え方に基づいて書きました。次のプロジェクト用に高度なカスタム Django ボイラープレートを作成することもできます。

この記事では、Linux Ubuntu マシンを使用していることを前提としています。この記事全体を通じて、一部のコード行は $ 記号で始まります。これらは、この行が端末に挿入されるべきであることを強調するために使用されます。必ず $ 記号を付けずに行をコピーしてください。

仮想環境

Python ベースのアプリケーションを開発する際には、サードパーティ パッケージの使用が継続的に行われます。これらのパッケージは頻繁に更新されるため、整理しておくことが重要です。同じローカル マシン上で開発するプロジェクトが増えると、各パッケージの現在のバージョンを追跡することが困難になります。異なるプロジェクトに同じパッケージの異なるバージョンを使用することはできません。さらに、あるプロジェクトのパッケージを更新すると、別のプロジェクトの機能が壊れる可能性があり、その逆も同様です。

そこで Python 仮想環境が役立ちます。仮想環境をインストールするには、次を使用します。

$ 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

次の行をファイルの最後に追加します。

. /usr/local/bin/virtualenvwrapper.sh

次に、以下を実行します。

$ . .bashrc

インストール後、次のように入力してプロジェクト用の新しい仮想環境を作成します。

$ mkvirtualenv project_name

仮想環境のコンテキスト内にいると、次のようなプレフィックスがターミナルに追加されることに気づくでしょう。

(project_name) ofir@playground:~$

仮想環境を非アクティブ化 (終了) し、ローカル マシンのメイン Python コンテキストに戻るには、次のコマンドを使用します。

$ deactivate

仮想環境コンテキストをアクティブ化 (開始) するには、次を使用します。

$ workon project_name

ローカル マシンに存在する仮想環境を一覧表示するには、次を使用します。

$ lsvirtualenv

プロジェクトの依存関係 (パッケージ) をマシン上の仮想環境に保持すると、それらを隔離された環境に保持できます。これらは 1 つ (または複数) のプロジェクトにのみ使用します。新しい仮想環境を作成するときは、パッケージがインストールされていない新しい環境を開始することになります。次に、たとえば次のように使用できます。

(project_name) $ pip install Django

仮想環境に Django をインストールする場合、または:

(project_name) $ pip install Django==1.11

環境内からのみアクセス可能な Django バージョン 1.11 をインストールする場合。

メインの Python インタープリターも、マシン上の他の仮想環境も、インストールしたばかりの新しい Django パッケージにはアクセスできません。

仮想環境のコンテキストで、仮想環境を使用して runserver コマンドを使用するには、次のコマンドを使用します。

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

同様に、仮想環境内から Python インタープリターに入る場合は、次のように入力します。

(project_name) $ python

環境内にすでにインストールされているパッケージにアクセスできます。

要件

要件は、プロジェクトの実行中に使用する Python パッケージ (依存関係) のリストであり、各パッケージのバージョンも含まれます。 requirements.txt ファイルの例を次に示します。

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

requirements.txt ファイルを最新の状態に保つことは、他の開発者と適切にコラボレーションするために不可欠です。実稼働環境を適切に構成しておくためにも重要です。このファイルをコード リポジトリに含めると、ターミナルで 1 行を実行するだけで、仮想環境にインストールされているすべてのパッケージを更新できます。そうすれば、新しい開発者をすぐに立ち上げて稼働させることができます。

新しい requirements.txt を生成するか、既存のものを更新するには、仮想環境内から次を使用します。

(project_name) $ pip freeze > requirements.txt

便宜上、このコマンドは Git リポジトリによって追跡されているフォルダーで実行してください。これにより、コードの他のインスタンスも requirements.txt ファイルにアクセスできるようになります。

新しい開発者がチームに参加する場合、または requirements.txt ファイルにリストされているのと同じパッケージを使用して新しい環境を構成する場合は、仮想環境コンテキストで次のコマンドを実行します。

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

ファイルにリストされているすべての要件は、すぐに仮想環境にインストールされます。 requirements.txt の正確なリストに適合するように、古いバージョンは更新され、新しいバージョンはダウングレードされます。ただし、注意してください。環境の間には、それでも尊重したい違いがある可能性があります。

これらのコマンドをワークフローに統合することを強くお勧めします。コードをリポジトリにプッシュする前にrequirements.txtファイルを更新し、リポジトリからコードをプルした後にrequirements.txtファイルをインストールします。

settings.py 構成の改善

Django には、非常に基本的でありながら便利な settings.py ファイルが最初から付属しています。これにより、プロジェクトの主要で最も役立つ構成が定義されます。 settings.py ファイルは非常に簡単です。ただし、チームで作業する開発者として、または運用環境をセットアップするときに、複数の基本的な settings.py ファイルが必要になる場合があります。

複数の設定ファイルを使用すると、次のように環境ごとにカスタマイズされた構成を簡単に定義できます。

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

settings.py ファイルを構成するための拡張アプローチを紹介します。これにより、さまざまなバージョンを維持し、いつでも、どの環境でも必要なバージョンを使用できます。

まず、settings.py ファイル パスに移動します。

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

次に、settings という新しいモジュールを作成します (モジュールは __init__.py ファイルを含むフォルダーです)。

(project_name) $ mkdir settings

ここで、settings.py ファイルの名前をbase.py に変更し、作成した新しいモジュール内に配置します。

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

この例では、開発環境用に 1 つの設定ファイルを構成し、実稼働環境用に 1 つの設定ファイルを構成すると仮定します。同じチームの異なる開発者は、まったく同じアプローチを使用して異なる設定ファイルを定義できます。

開発環境用に以下を作成します。

(project_name) $ nano settings/development.py

次に、次のように入力します。

from .base import *

DEBUG = True

Ctrl + O、Enter、Ctrl + X を押してファイルを保存します。

実稼働環境用に以下を作成します。

(project_name) $ nano settings/production.py

そして次のように入力します:

from .base import *

DEBUG = False
ALLOWED_HOSTS = [‘app.project_name.com’, ]

特定の環境の設定を追加または更新したいときはいつでも、独自の設定ファイルで簡単に実行できるようになりました。

あなたは疑問に思っているかもしれません — Django は各環境にロードする設定ファイルをどのようにして知るのでしょうか?これが、__init__.py ファイルが使用される目的です。たとえば、Django がサーバーの実行時に読み込んでいた settings.py を検索するとき、settings.py ファイルではなく設定モジュールを検索するようになりました。しかし、Django に関する限り、それが __init__.py ファイルを含むモジュールである限り、まったく同じです。 Django は __init__.py ファイルをロードし、そこに書かれた内容をすべて実行します。

したがって、次のコマンドを実行して、 __init__.py ファイル内にロードする設定ファイルを定義する必要があります。

(project_name) $ settings/__init__.py

次に、実稼働環境の場合は、たとえば次のように入力します。

from .production import *

こうすることで、Django は起動するたびにすべての base.py およびproduction.py 設定を読み込みます。魔法？

ここで残っている唯一の設定は、__init__.py を .gitignore ファイル内に保持して、プッシュとプルに含まれないようにすることです。新しい環境をセットアップしたら、設定モジュール内に新しい __init__.py ファイルを作成することを忘れないでください。次に、前と同じように、必要な設定ファイルをインポートします。

この記事では、Django プロジェクトをより適切にセットアップするための 3 つのベスト プラクティスについて説明しました。

• 仮想環境内での作業
• requirements.txt ファイルを最新の状態に保ち、ワークフローで継続的に使用します。
• より適切なプロジェクト設定配列のセットアップ

前回のプロジェクトでこれらのベスト プラクティスに従いましたか?共有したい洞察はありますか?コメントは大歓迎です。

これは役に立ちましたか?もしそうなら、より多くの人に記事を見てもらうために拍手をお願いします。

これは、Django 開発のベスト プラクティスに関するシリーズのパート 1 です。次のパーツが入手可能になったら、すぐに更新情報を入手するには、私をフォローしてください。

テクノロジー起業家向けの素晴らしいヒントを、CodingStartups でさらに見つけてください。