Escribiendo su primer parche para Django

Introducción

¿Interesado en retribuir un poco a la comunidad? Quizás ha encontrado un fallo en Django que le gustaría ver solucionado, o quizás hay una pequeña característica que quiera agregar.

Contribuyendo al propio proyecto de Django es la mejor forma de ver sus propios problemas abordados. Puede parecer desalentador al inicio, pero es un camino ya conocido: con documentación, herramientas, y una comunidad que le ayudará. Le guiaremos por todo el proceso, así pueda aprender con el ejemplo.

¿Para quién es este tutorial?

Ver también

Si usted está buscando una referencia sobre cómo hacer contribuciones, consulte la documentación Submitting patches.

Para este tutorial, esperamos que tengas al menos un entendimiento básico de cómo funciona Django. Esto significa que debes sentirte cómodo al repasar los tutoriales que se encuentran en escribiendo tu primer app de Django. Además, debes tener una buena comprensión de Python. Pero si no la tienes, “Inmersión en Python`__ es un fantástico (y gratis) libro en línea para de programadores Python principiantes.

Aquellos de ustedes que no están familiarizados con los sistemas de control de versiones y Trac encontrarán que este tutorial y sus vínculos incluyen información suficiente para empezar. Sin embargo, es probable que quiera leer un poco más acerca de estas diferentes herramientas si usted planea contribuir a Django con regularidad.

Sin embargo, en su mayor parte, este tutorial trata de explicar tanto como sea posible, de modo que pueda ser de utilidad para la audiencia más amplia.

Dónde obtener ayuda:

Si tiene problemas para seguir este tutorial, por favor envíe un mensaje al Django Forum, django-developers, o visite #django-dev en irc.libera.chat para charlar con otros usuarios de Django que puedan ayudarle.

¿Qué cubre esta guía?

Le mostraremos cómo contribuir con parches para Django por primera vez. Al final de este tutorial, contará con un entendimiento básico sobre las herramientas y procesos implicados. Específicamente, cubriremos lo siguiente:

• Instalando Git.
• Descargue una copia de la versión de desarrollo de Django
• Conjunto de pruebas de funcionamiento de Django.
• Escribiendo una prueba para su parche.
• Escribiendo el código para su parche.
• Probando su parche.
• Enviar una solicitud de pull.
• Dónde buscar más información.

Una vez que haya terminado el tutorial, puede revisar el resto de la documentación para contribuir con Django. Contiene una gran cantidad de información de lectura obligatoria para todo el que desee convertirse en colaborador habitual de Django. Si tiene preguntas, es probable que obtenga las respuestas.

¡Python 3 es requerido!

La versión actual de Django no soporta Python 2.7. Obtenga Python 3 en la página de descargas de Python o con el gestor de paquetes de su sistema operativo.

Para los usuarios de Windows

Puede consultar Instale Python en la documentación de Windows para obtener orientación adicional.

Código de Conducta

Como un colaborador, usted puede ayudarnos a mantener abierta e inclusiva la comunidad Django. Por favor lea y siga nuestro Código de conducta.

Instalando Git

Para este tutorial, necesitará instalar Git para descargar la versión actual de desarrollo de Django y generar archivos de revisión de los cambios que realice.

Para revisar si tiene o no instalado Git , ejecute git en la línea de comandos. Si recibe un mensaje diciendo que el comando no pudo ser encontrado, tendrá que descargarlo e instalarlo. Consulte la página de descarga de Git.

Si no está familiarizado con Git, siempre se puede encontrar más información sobre sus comandos (una vez instalado) escribiendo git help en la línea de comandos.

Obtenga una copia de la versión de desarrollo de Django

El primer paso para contribuir con Django es obtener una copia del código fuente. Primero, haga un fork de Django en GitHub. Después, desde la línea de comandos, use el comando cd para navegar hasta el directorio donde quiera que se aloje su copia local de Django.

Descargue el repositorio de código fuente de Django con el siguiente comando:

Linux/macOS

$ git clone https://github.com/YourGitHubName/django.git

Windows

...\> git clone https://github.com/YourGitHubName/django.git

¿Conexión de bajo ancho de banda?

Puede añadir el argumento --depth 1 al comando git clone para evitar descargar todo el historial de commits de Django, el cual reduce la transferencia de datos de ~250MB a ~70MB

Ahora que tiene una copia local de Django, puede instalarla como si fuera a instalar cualquier paquete utilizando pip. La forma más conveniente de hacerlo es mediante un entorno virtual, que es una función incorporada en Python que le permite mantener un directorio separado de paquetes instalados para cada uno de sus proyectos para que no interfieran entre sí.

Es una buena idea mantener todos sus entornos virtuales en un solo lugar, por ejemplo, en `` virtualenvs /`` en su directorio de inicio.

Cree un nuevo entorno virtual ejecutando:

Linux/macOS

$ python3 -m venv ~/.virtualenvs/djangodev

Windows

...\> py -m venv %HOMEPATH%\.virtualenvs\djangodev

La ruta es donde se guardará el nuevo entorno en su computadora.

El último paso para configurar su entorno virtual es activarlo:

$ source ~/.virtualenvs/djangodev/bin/activate

Si el comando source no está disponible, puede intentar usar un punto en su lugar:

$ . ~/.virtualenvs/djangodev/bin/activate

Debe activar el entorno virtual cada vez que abra una nueva ventana de la terminal.

Para los usuarios de Windows

Para activar su entorno virtual en Windows ejecute:

...\> %HOMEPATH%\.virtualenvs\djangodev\Scripts\activate.bat

El nombre del entorno virtual actualmente activado se muestra en la línea de comandos para ayudarlo a realizar un seguimiento de cuál está utilizando. Todo lo que instale a través de pip mientras se muestre este nombre se instalará en ese entorno virtual, aislado de otros entornos y paquetes del sistema.

Continúe e instale la copia previamente clonada de Django:

Linux/macOS

$ python -m pip install -e /path/to/your/local/clone/django/

Windows

...\> py -m pip install -e \path\to\your\local\clone\django\

La versión instalada de Django ahora apunta a su copia local al instalarlo en modo editable. Verá inmediatamente cualquier cambio que haga en él, lo cual es de gran ayuda al escribir su primer parche.

Creando proyectos con una copia local de Django.

It may be helpful to test your local changes with a Django project. First you have to create a new virtual environment, install the previously cloned local copy of Django in editable mode, and create a new Django project outside of your local copy of Django. You will immediately see any changes you make to Django in your new project, which is of great help when writing your first patch, especially if testing any changes to the UI.

You can follow the tutorial for help in creating a Django project.

Ejecutando el conjunto de pruebas de Django por primera vez

Cuando contribuya a Django, es muy importante que sus cambios de código no introduzcan errores en otras áreas de Django. Una forma de comprobar que Django sigue funcionando después de hacer sus cambios es ejecutar la suite de pruebas de Django. Si todas las pruebas siguen pasando, entonces puedes estar razonablemente seguro de que sus cambios funcionan y no han roto otras partes de Django. Si nunca ha ejecutado la suite de pruebas de Django antes, es una buena idea ejecutarla una vez antes para familiarizarse con su salida.

Antes de ejecutar el conjunto de pruebas, ingrese al directorio de Django tests/ utilizando el comando cd tests y instale las dependencias de prueba ejecutando:

Linux/macOS

$ python -m pip install -r requirements/py3.txt

Windows

...\> py -m pip install -r requirements\py3.txt

Si encuentra un error durante la instalación, es posible que a su sistema le falte una dependencia para uno o más de los paquetes de Python. Consulte la documentación del paquete que falla o busque en la web el mensaje de error que encuentre.

Ahora estamos listos para ejecutar el conjunto de pruebas. Si estás utilizando GNU/Linux, macOS o alguna otra distribución de Unix, ejecute:

Linux/macOS

$ ./runtests.py

Windows

...\> runtests.py 

Ahora siéntese y relájese. La suite de pruebas completa de Django tiene miles de pruebas y tarda al menos unos minutos en ejecutarse, dependiendo de la velocidad de su computadora.

Mientras se ejecuta la suite de pruebas de Django, verá una secuencia de caracteres que representan el estado de cada prueba a medida que se completa. `` E`` indica que un error se planteó durante una prueba, y `` F`` indica las afirmaciones de una prueba fallida. Ambos de estos son considerados como fallas de prueba. Mientras tanto, `` x`` y `` s`` indican fallas esperadas y pruebas omitidas, respectivamente. Los puntos indican pruebas superadas.

Las pruebas omitidas se deben usualmente a la ausencia de bibliotecas externas requeridas para la ejecución de las pruebas; ver Running all the tests para la lista de dependencias y estar seguro de instalar aquellas relacionadas con los cambios que está haciendo (no necesitamos ninguna para esta tutorial). Algunas pruebas son especificas de un backend de base de datos particular y serán omitidas si no se está probando ese backend. SQLite es el backend por defecto para las pruebas. Para ejecutar las pruebas con un backend diferente ver Using another settings module.

Una vez que las pruebas finalicen, usted debe ser recibido con un mensaje que le informa si el conjunto de pruebas pasó o falló. Dado que aún no ha realizado ningún cambio en el código de Django, todo el conjunto de pruebas debe pasar. Si obtiene fallos o errores asegúrese de que ha seguido correctamente todos los pasos anteriores . Consulte: ref: Ejecutar pruebas unitarias para más información.

Ten en cuenta que la última rama «main» de Django no siempre es estable. Cuando desarrolles contra «main», puedes comprobar Django’s continuous integration builds para determinar si los fallos son específicos de tu máquina o si también están presentes en las builds oficiales de Django. Si haces clic para ver una compilación en particular, verás la «Matriz de configuración» que muestra los fallos desglosados por versión de Python y backend de base de datos específicos.

Nota

For this tutorial and the ticket we’re working on, testing against SQLite is sufficient, however, it’s possible (and sometimes necessary) to run the tests using a different database. When making UI changes, you will need to run the Selenium tests.

Trabajando en una característica

Para este tutorial, trabajaremos sobre un «falso ticket» como un caso de estudio. Estos son los detalles imaginarios:

Ticket #99999 – Permitir hacer unas tostadas

Django debe proporcionar una función django.shortcuts.make_toast() que devuelva 'toast'.

Bueno, ahora implemente la característica y sus pruebas asociadas.

Creando una rama para su parche

Antes de hacer algún cambio, cree una nueva rama para el ticket:

Linux/macOS

$ git checkout -b ticket_99999

Windows

...\> git checkout -b ticket_99999

Puede elegir cualquier nombre que desee para la rama, por ejemplo «ticket_99999». Todos los cambios realizados en esta rama será específico para el ticket y no afecta la copia principal del código previamente clonado

Escribiendo algunas pruebas para su reporte

En la mayoría de los casos, para que un parche sea aceptado en Django tiene que incluir pruebas. Para los parches de corrección de bugs, esto significa escribir una prueba de regresión para asegurar que el bug no sea reintroducido en Django más adelante. Una prueba de regresión debe ser escrita de forma tal que falle mientras que todavía exista el bug y pase una vez que el bug se haya corregido. Para los parches que contienen nuevas características, tendrás que incluir pruebas que garanticen que dichas características estén funcionando correctamente. Los parches también deben fallar cuando la nueva característica no esté presente y por lo tanto, pasar una vez que haya sido aplicada.

Una buena forma de hacer esto, es escribir primero sus nuevas pruebas antes de realizar cualquier cambio en el código. Este estilo de desarrollo se llama desarrollo guiado por pruebas y se puede aplicar tanto a proyectos completos como a parches individuales. Después de escribir sus pruebas, ejecútelas para asegurarse de que en efecto fallan (ya que aún no ha corregido ese bug o añadido esa característica). Si sus nuevas pruebas no fallan, tendrá que arreglarlas de manera que lo hagan. Después de todo, una prueba de regresión que pasa sin importar si un error está presente, no es muy útil en prevenir que ese error se repita en el futuro.

Ahora a nuestro ejemplo práctico.

Escribiendo una prueba para el ticket #99999

Para resolver este problema, vamos a añadir una función make_toast() al módulo django.shortcuts. Primero vamos a escribir un test que intente usar la función y comprobar que su salida parezca correcta.

Navegue a la carpeta tests/shortcuts/ y cree un nuevo fichero llamado test_make_toast.py. Añada el siguiente código:

from django.shortcuts import make_toast
from django.test import SimpleTestCase


class MakeToastTests(SimpleTestCase):
    def test_make_toast(self):
        self.assertEqual(make_toast(), "toast")

Esta prueba comprueba que la función make_toast() devuelve 'toast'

Pero este asunto de las pruebas parece un poco difícil…

Si usted nunca había tenido que lidiar con las pruebas anteriormente, pueden parecer un poco difíciles de escribir a primera vista. Afortunadamente, las pruebas son un tema muy importante en la programación, así que hay mucha información disponible:

• Un buen primer vistazo a las pruebas de escritura para Django se puede encontrar en la documentación en: doc:/topics/testing/overview.
• Inmersión en Python (un libro en línea gratis para los desarrolladores principiantes de Python) incluye una gran introducción a las pruebas unitarias.
• Después de leer esos, si quieres algo un poco mas sustancioso para hincar el diente, siempre está la documentación de unittest de Python.

Ejecutando su nueva prueba

Ya que no hemos hecho ninguna modificación en django.shortcuts, nuestra prueba debería fallar. Vamos a ejecutar todas las pruebas en la carpeta shortcuts para asegurarnos de que es lo que realmente ocurre. Use cd para cambiarse al directorio tests/ de Django y ejecute:

Linux/macOS

$ ./runtests.py shortcuts

Windows

...\> runtests.py shortcuts

Si las pruebas se ejecutaron correctamente, debería ver un fallo correspondiente al método de prueba que agregamos, con este error:

ImportError: cannot import name 'make_toast' from 'django.shortcuts'

Si todos las pruebas pasaron, entonces querrá asegurarse de haber agregado la nueva prueba mostrada arriba a la carpeta y nombre de archivo correspondiente.

Escribiendo el código para su ticket

Ahora agregaremos la función make_toast().

Navegue al directorio django/ y edite shortcuts.py. Al final del archivo añada:

def make_toast():
    return "toast"

Ahora necesitamos asegurarnos de que la prueba que escribimos anteriormente pase, para poder ver si el código que agregamos funciona correctamente. Nuevamente, navegue al directorio tests/ de Django y ejecute:

Linux/macOS

$ ./runtests.py shortcuts

Windows

...\> runtests.py shortcuts

Todo debería funcionar. Si no lo hace, asegúrese de haber agregado correctamente la función al archivo correcto.

Ejecutando el conjunto de pruebas de Django por segunda vez

Una vez que hayas verificado que el parche y el test están funcionando correctamente, es una buena idea ejecutar toda la batería de tests de Django para verificar que tus modificaciones no ha introducido errores en otras áreas de Django. Aunque todos los tests Django pasen exitosamente no garantiza que tu código esté libre de errores, ayuda a identificar muchos errores y regresiones que de otro modo podrían pasar desapercibidos.

Para ejecutar todo el conjunto de pruebas de Django, cambie al directorio tests/ de Django y ejecute:

Linux/macOS

$ ./runtests.py

Windows

...\> runtests.py 

Escribiendo la documentación

Esta es una nueva funcionalidad, por tlo anto debe ser documentada. Edite docs/topics/http/shortcuts.txt y agregue lo siguiente al final del archivo:

``make_toast()``
================

.. function:: make_toast()

.. versionadded:: 2.2

Returns ``'toast'``.

Dado que esta nueva característica estará en una próxima versión, también se agrega a las notas de la versión para la próxima versión de Django. Abra las notas de la versión más reciente en docs/releases/, que en el momento de escribir esto es 2.2.txt. Agregue una nota debajo del encabezado «Minor Features».

:mod:`django.shortcuts`
~~~~~~~~~~~~~~~~~~~~~~~

* The new :func:`django.shortcuts.make_toast` function returns ``'toast'``.

Para obtener más información sobre escribir la documentación, incluyendo una explicación de lo que se trata el fragmento versionadded, consulte Writing documentation. Esa página incluye también una explicación de cómo generar una copia de la documentación localmente, por lo que puede obtener una vista previa del código HTML que se generará.

Previsualización de sus cambios

Es el momento de revisar todos los cambios realizados en nuestro parche. Para poner en escena todos los cambios listos para su confirmación, ejecuta:

Linux/macOS

$ git add --all

Windows

...\> git add --all

Luego muestra las diferencias entre su copia actual de Django (con sus cambios) y la revisión que inicialmente verificó anteriormente en el tutorial con:

Linux/macOS

$ git diff --cached

Windows

...\> git diff --cached

Use las flechas del teclado para moverse arriba y abajo.

diff --git a/django/shortcuts.py b/django/shortcuts.py
index 7ab1df0e9d..8dde9e28d9 100644
--- a/django/shortcuts.py
+++ b/django/shortcuts.py
@@ -156,3 +156,7 @@ def resolve_url(to, *args, **kwargs):

     # Finally, fall back and assume it's a URL
     return to
+
+
+def make_toast():
+    return 'toast'
diff --git a/docs/releases/2.2.txt b/docs/releases/2.2.txt
index 7d85d30c4a..81518187b3 100644
--- a/docs/releases/2.2.txt
+++ b/docs/releases/2.2.txt
@@ -40,6 +40,11 @@ database constraints. Constraints are added to models using the
 Minor features
 --------------

+:mod:`django.shortcuts`
+~~~~~~~~~~~~~~~~~~~~~~~
+
+* The new :func:`django.shortcuts.make_toast` function returns ``'toast'``.
+
 :mod:`django.contrib.admin`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~

diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index 7b3a3a2c00..711bf6bb6d 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -271,3 +271,12 @@ This example is equivalent to::
         my_objects = list(MyModel.objects.filter(published=True))
         if not my_objects:
             raise Http404("No MyModel matches the given query.")
+
+``make_toast()``
+================
+
+.. function:: make_toast()
+
+.. versionadded:: 2.2
+
+Returns ``'toast'``.
diff --git a/tests/shortcuts/test_make_toast.py b/tests/shortcuts/test_make_toast.py
new file mode 100644
index 0000000000..6f4c627b6e
--- /dev/null
+++ b/tests/shortcuts/test_make_toast.py
@@ -0,0 +1,7 @@
+from django.shortcuts import make_toast
+from django.test import SimpleTestCase
+
+
+class MakeToastTests(SimpleTestCase):
+    def test_make_toast(self):
+        self.assertEqual(make_toast(), 'toast')

Cuando hayas terminado de revisar el parche presiona q para volver a la línea de comandos. Si el contenido del parche se ve bien es tiempo de consumar los cambios.

Confirmando los cambios en el parche

Para confirmar los cambios:

Linux/macOS

$ git commit

Windows

...\> git commit

Esto abre un editor de texto para escribir el mensaje de confirmación. Siga las guías para mensajes de confirmación y escriba un mensaje como:

Fixed #99999 -- Added a shortcut function to make toast.

Enviando la confirmación y haciendo una solicitud de fusión

After committing the patch, send it to your fork on GitHub (substitute «ticket_99999» with the name of your branch if it’s different):

Linux/macOS

$ git push origin ticket_99999

Windows

...\> git push origin ticket_99999

Puede crear una solicitud de fusión visitando La página GitHub de Django. Verá su rama en «Your recently pushed branches». Haga clic en «Compare & pull request».

Por favor, no lo haga para este tutorial, pero en la siguiente página que se muestra una vista previa del parche, debería hacer clic en «Create pull request».

Próximos pasos

¡Enhorabuena, ha aprendido cómo hacer una solicitud de fusión a Django! Encontrará detalles de técnicas más avanzadas que puede necesitar en Working with Git and GitHub.

Ahora puedes dar un buen uso a esas habilidades ayudando a mejorar la base de código de Django.

Más información para los nuevos colaboradores

Antes de que se involucre mucho en la escritura de parches para Django, hay algo más de información sobre cómo contribuir a la que probablemente debería echarle un vistazo:

• Debe asegurarse de leer la documentación de Django sobre reclamar tickets y enviar parches. Esta incluye la etiqueta de Trac, cómo reclamar tickets para uno mismo, el estilo esperado de codificación para parches y muchos otros detalles importantes.
• Las personas que colaboran por primera vez también deben leer la documentación para los colaboradores principiantes de Django. Tiene muchos buenos consejos para aquellos de nosotros que somos nuevos en esto de colaborar con Django.
• Después de ellos, si todavía quiere más información sobre cómo contribuir, siempre se puede navegar por el resto de la documentación de Django sobre cómo contribuir. Este contiene un montón de información útil y debe ser su primera fuente para responder a cualquier pregunta que pueda tener.

Encontrando su primer ticket real

Una vez que haya revisado parte de esa información, estará listo para salir y encontrar un ticket al cual escribirle un parche. Preste especial atención a los tickets con el criterio de «easy pickings». Estos tickets son a menudo de carácter mucho más simples y son geniales para los que colaboran por primera vez. Una vez que esté familiarizado con como contribuir con Django, puede pasar a escribir parches para los tickets más difíciles y complicados.

If you just want to get started already (and nobody would blame you!), try taking a look at the list of easy tickets that need patches and the easy tickets that have patches which need improvement. If you’re familiar with writing tests, you can also look at the list of easy tickets that need tests. Remember to follow the guidelines about claiming tickets that were mentioned in the link to Django’s documentation on claiming tickets and submitting patches.

¿Qué hay después de crear una solicitud de fusión?

Después de que un ticket tiene un parche, necesita ser revisado por un segundo par de ojos. Después de enviar una solicitud de fusión asegúrese de actualizar los metadatos del ticket mediante el establecimiento de banderas en el ticket para decir «tiene parche», «no necesita pruebas», etc, para que otros puedan encontrarlo para su revisión. Contribuir no necesariamente siempre significa escribir un parche desde cero. Revisar parches existentes es también una contribución muy útil. Consulte: doc:/internals/contributing/triaging-tickets para más detalles.