# documentación de Django - 6.0.7

# Escribiendo su primera contribución para Django

## Introducción

Interested in giving back to the community a little? Maybe you’ve found a bug in Django that you’d like to see fixed, or maybe there’s a small feature you want added (but remember that proposals for new features should follow the process for suggesting new features).

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 contributions.

Para este tutorial, esperamos que tenga al menos un entendimiento básico de cómo funciona Django. Esto significa que debe sentirse cómodo al repasar los tutoriales que se encuentran en escribiendo su primer aplicación de Django. Además, debe tener una buena comprensión de Python. Pero si no la tiene, Dive Into Python es un fantástico (y gratuito) libro en línea para 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:

If you’re having trouble going through this tutorial, please post a message on the Django Forum or drop by the Django Discord server to chat with other Django users who might be able to help.

### ¿Qué cubre esta guía?

We’ll be walking you through contributing to Django for the first time. By the end of this tutorial, you should have a basic understanding of both the tools and the processes involved. Specifically, we’ll be covering the following:

- Instalando Git.

- Descargue una copia de la versión de desarrollo de Django

- Conjunto de pruebas de funcionamiento de Django.

- Escribiendo un prueba para sus cambios

- Escribiendo el código para sus cambios

- Pruebe sus cambios.

- Enviar una solicitud de pull.

- Dónde buscar más información.

Once you’re done with the tutorial, you can look through the rest of Django’s documentation on contributing. It contains lots of great information and is a must-read for anyone who’d like to become a regular contributor to Django. If you’ve got questions, it’s probably got the answers.

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 de desarrollo actual de Django y generar una rama para 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:

/ 

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

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

¿Conexión de bajo ancho de banda?

You can add the `--depth 1` argument to `git clone` to skip downloading all of Django’s commit history, which reduces data transfer from ~250 MB to ~70 MB.

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:

/ 

    $ python3 -m venv ~/.virtualenvs/djangodev

    ...\> 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:

/ 

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

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

The installed version of Django is now pointing at your local copy by installing in editable mode. You will immediately see any changes you make to it, which is of great help when testing your first contribution.

## 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:

/ 

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

    ...\> 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 la suite de prueba:

/ 

    $ ./runtests.py

    ...\> 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.

While Django’s test suite is running, you’ll see a stream of characters representing the status of each test as it completes. `E` indicates that an error was raised during a test, and `F` indicates that a test’s assertions failed. Both of these are considered to be test failures. Meanwhile, `x` and `s` indicate expected failures and skipped tests, respectively. Dots indicate passing tests.

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 debería recibir un mensaje informándole 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 debería pasar. Si obtiene fallos o errores, asegúrese de que ha seguido correctamente todos los pasos anteriores . Consulte Running the unit tests 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 nueva funcionalidad aprobada

For this tutorial, we’ll work on a «fake accepted ticket» as a case study. Here are the imaginary details:

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

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

/ 

    $ git checkout -b ticket_99999

    ...\> 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

In most cases, for a contribution to be accepted into Django it has to include tests. For bug fix contributions, this means writing a regression test to ensure that the bug is never reintroduced into Django later on. A regression test should be written in such a way that it will fail while the bug still exists and pass once the bug has been fixed. For contributions containing new features, you’ll need to include tests which ensure that the new features are working correctly. They too should fail when the new feature is not present, and then pass once it has been implemented.

A good way to do this is to write your new tests first, before making any changes to the code. This style of development is called test-driven development and can be applied to both entire projects and single changes. After writing your tests, you then run them to make sure that they do indeed fail (since you haven’t fixed that bug or added that feature yet). If your new tests don’t fail, you’ll need to fix them so that they do. After all, a regression test that passes regardless of whether a bug is present is not very helpful at preventing that bug from reoccurring down the road.

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:

/ 

    $ ./runtests.py shortcuts

    ...\> 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:

/ 

    $ ./runtests.py shortcuts

    ...\> 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

Once you’ve verified that your changes and test are working correctly, it’s a good idea to run the entire Django test suite to verify that your change hasn’t introduced any bugs into other areas of Django. While successfully passing the entire test suite doesn’t guarantee your code is bug free, it does help identify many bugs and regressions that might otherwise go unnoticed.

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

/ 

    $ ./runtests.py

    ...\> 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:: 6.2

    Returns ``'toast'``.

Since this new feature will be in an upcoming release it is also added to the release notes for the next version of Django. Open the release notes for the latest version in `docs/releases/`, which at time of writing is `6.2.txt`. Add a note under the «Minor Features» header:

    :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

Ahora es momento de revisar los cambios realizados en la rama. Para preparar todos los cambios que estén listos para la confirmación, ejecute:

/ 

    $ git add --all

    ...\> 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:

/ 

    $ git diff --cached

    ...\> 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/6.2.txt b/docs/releases/6.2.txt
    index 7d85d30c4a..81518187b3 100644
    --- a/docs/releases/6.2.txt
    +++ b/docs/releases/6.2.txt
    @@ -34,6 +34,11 @@
     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:: 6.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')

When you’re done previewing the changes, hit the `q` key to return to the command line. If the diff looked okay, it’s time to commit the changes.

## Confirmando los cambios

Para confirmar los cambios:

/ 

    $ git commit

    ...\> 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 changes, send it to your fork on GitHub (substitute «ticket_99999» with the name of your branch if it’s different):

/ 

    $ git push origin ticket_99999

    ...\> 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».

Please don’t do it for this tutorial, but on the next page that displays a preview of the changes, you would click «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

Before you get too into contributing to Django, there’s a little more information on contributing that you should probably take a look at:

- You should make sure to read Django’s documentation on claiming tickets and submitting pull requests. It covers Trac etiquette, how to claim tickets for yourself, expected coding style (both for code and docs), and many other important details.

- 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

Once you’ve looked through some of that information, you’ll be ready to go out and find a ticket of your own to contribute to. Pay special attention to tickets with the «easy pickings» criterion. These tickets are often much simpler in nature and are great for first time contributors. Once you’re familiar with contributing to Django, you can start working on more difficult and complicated tickets.

If you just want to get started already (and nobody would blame you!), try taking a look at the list of easy tickets without a branch and the easy tickets that have branches 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 branches.

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

After a ticket has a branch, it needs to be reviewed by a second set of eyes. After submitting a pull request, update the ticket metadata by setting the flags on the ticket to say «has patch», «doesn’t need tests», etc, so others can find it for review. Contributing doesn’t necessarily always mean writing code from scratch. Reviewing open pull requests is also a very helpful contribution. See Clasificando tickets for details.