Mejore su proyecto Django con estas mejores prácticas

Programación

Django es un marco robusto, de código abierto y basado en Python para crear aplicaciones web. Su popularidad ha aumentado durante los últimos años, y ya está maduro y se usa ampliamente con una gran comunidad detrás.

Entre otros marcos basados ​​en Python para crear aplicaciones web (como Flask y Pyramid), Django es, con mucho, el más popular. Es compatible con Python versión 2.7 y Python 3.6. Pero en el momento de este artículo, Python 2.7 sigue siendo la versión más accesible en términos de comunidad, paquetes de terceros y documentación en línea. Django es seguro cuando se usa correctamente y proporciona grandes dimensiones de flexibilidad. Es el camino a seguir cuando se desarrollan aplicaciones del lado del servidor con Python.

Como desarrollador experimentado de Python y Django, compartiré contigo algunas de las mejores prácticas para una configuración de Django que he aprendido y recopilado a lo largo de los años. Ya sea que tenga algunos proyectos de Django en su haber o que esté a punto de comenzar el primero desde cero, las mejores prácticas descritas aquí pueden ayudarlo a crear mejores aplicaciones en el futuro.

Escribí este artículo con una mentalidad muy práctica para que pueda agregar algunas herramientas a su caja de herramientas de desarrollo de inmediato. Incluso puede crear una plantilla de Django personalizada avanzada para sus próximos proyectos.

A los efectos de este artículo, supongo que está utilizando una máquina Linux Ubuntu. A lo largo del artículo, algunas líneas de código comienzan con un $signo. Estos se utilizan para enfatizar que esta línea debe insertarse en el terminal. Asegúrese de copiar la línea sin el $letrero.

Ambiente virtual

Al desarrollar aplicaciones basadas en Python, el uso de paquetes de terceros es algo continuo. Estos paquetes se actualizan con frecuencia, por lo que mantenerlos organizados es fundamental. Al desarrollar más y más proyectos en la misma máquina local, es un desafío realizar un seguimiento de la versión actual de cada paquete. Es imposible utilizar diferentes versiones del mismo paquete para diferentes proyectos. Además, actualizar un paquete en un proyecto puede romper la funcionalidad en otro y viceversa.

Ahí es donde el entorno virtual de Python resulta útil. Para instalar el entorno virtual, utilice:

$ 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

Agregue esta línea al final del archivo:

. /usr/local/bin/virtualenvwrapper.sh

Luego ejecuta:

$ . .bashrc

Después de la instalación, cree un nuevo entorno virtual para su proyecto escribiendo:

$ mkvirtualenv project_name

Mientras está en el contexto de su entorno virtual, notará que se agrega un prefijo al terminal, como:

(project_name) ofir@playground:~$

Para desactivar (salir) el entorno virtual y volver al contexto principal de Python de su máquina local, utilice:

$ deactivate

Para activar (iniciar) el contexto del entorno virtual, utilice:

$ workon project_name

Para enumerar los entornos virtuales existentes en su máquina local, use:

$ lsvirtualenv

Mantener las dependencias de su proyecto (paquetes) en un entorno virtual en su máquina le permite mantenerlas en un entorno aislado. Solo los usa para uno (o múltiples) proyectos. Al crear un nuevo entorno virtual, está iniciando un entorno nuevo sin paquetes instalados en él. Entonces puedes usar, por ejemplo:

(project_name) $ pip install Django

para instalar Django en su entorno virtual, o:

(project_name) $ pip install Django==1.11

para instalar la versión 1.11 de Django accesible solo desde el entorno.

Ni su intérprete principal de Python ni los demás entornos virtuales de su máquina podrán acceder al nuevo paquete de Django que acaba de instalar.

Para usar el comando runserver usando su entorno virtual, mientras está en el contexto del entorno virtual, use:

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

Del mismo modo, al ingresar al intérprete de Python desde el entorno virtual, escriba:

(project_name) $ python

Tendrá acceso a los paquetes que ya ha instalado dentro del entorno.

Requisitos

Los requisitos son la lista de paquetes de Python (dependencias) que usa su proyecto mientras se ejecuta, incluida la versión de cada paquete. Aquí hay un ejemplo de un requirements.txtarchivo:

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

Mantener su requirements.txtarchivo actualizado es esencial para colaborar adecuadamente con otros desarrolladores. También es importante para mantener su entorno de producción configurado correctamente. Este archivo, cuando se incluye en su repositorio de código, le permite actualizar todos los paquetes instalados en su entorno virtual ejecutando una sola línea en la terminal. Entonces puede poner en marcha nuevos desarrolladores en muy poco tiempo.

Para generar uno nuevo requirements.txto actualizar uno existente, utilice desde su entorno virtual:

(project_name) $ pip freeze > requirements.txt

Para su conveniencia, asegúrese de ejecutar este comando en una carpeta que está siendo rastreada por su repositorio de Git. Esto permite que otras instancias del código también tengan acceso al requirements.txtarchivo.

Si un nuevo desarrollador se une al equipo, o si desea configurar un nuevo entorno utilizando los mismos paquetes enumerados en el requirements.txtarchivo, ejecute en el contexto del entorno virtual:

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

Todos los requisitos enumerados en el archivo se instalarán inmediatamente en su entorno virtual. Las versiones anteriores se actualizarán y las versiones más nuevas se degradarán para ajustarse a la lista exacta de requirements.txt. Sin embargo, tenga cuidado: puede haber diferencias entre los entornos que aún desea respetar.

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.