Le dépôt de code source de Django

Lors du déploiement d’une application Django dans un environnement de production réel, il est pratiquement toujours indiqué d’utiliser une version officiellement empaquetée de Django.

Cependant, si vous souhaitez essayer du code en cours de développement d’une version à venir ou contribuer au développement de Django, vous aurez besoin d’accéder au dépôt du code source de Django.

Ce document présente la façon dont le dépôt de code est organisé et comment vous pouvez travailler avec lui et y faire des recherches.

Aperçu général

Le dépôt du code source de Django utilise Git pour suivre l’évolution du code à travers le temps, il est donc nécessaire de disposer d’une copie du client Git (programme nommé git) sur votre ordinateur, et il est conseillé de vous familiariser quelque peu avec les bases du fonctionnement de Git.

Le site Web de Git offre des téléchargements pour différents systèmes d’exploitation. Le site contient aussi une grande quantité de documentation.

Le dépôt Git de Django est accessible en ligne sur github.com/django/django. Il contient le code source complet de toutes les versions de Django que vous pouvez parcourir en ligne.

Le dépôt Git comprend plusieurs branches:

• main contient le code en développement principal qui est appelé à devenir la prochaine version publiée de Django. C’est là que la plupart des activités de développement ont lieu.
• stable/A.B.x sont les branches dans lesquelles se préparent les prochaines publications. Elles sont également utilisées pour les publications correctives et de sécurité qui sont produites en fonction des besoins à la suite de la publication initiale d’une version majeure.

Le dépôt Git contient aussi des étiquettes (tags). Il s’agit de versions figées à partir desquelles des versions de Django ont été produites depuis la version 1.0.

Un certain nombre de « tags » existent aussi sous le préfixe archive/ pour des travaux archivés.

Le code source du site Web Djangoproject.com se trouve à l’adresse github.com/django/djangoproject.com.

La branche principale main

Si vous souhaitez tester le code en cours de développement de la prochaine version de Django ou si vous aimeriez contribuer à Django en corrigeant des anomalies ou en développant de nouvelles fonctionnalités, vous aurez besoin d’obtenir le code de la branche main.

Note

Avant mars 2021, la branche principale s’appelait master.

Notez que vous obtiendrez la totalité de Django : en plus du module ` django` au premier niveau contenant le code Python, vous obtiendrez aussi une copie de la documentation de Django, la suite de tests, les scripts d’empaquetage et d’autres éléments divers. Le code de Django sera présent dans votre clone sous forme d’un répertoire nommé django.

Pour tester le code en cours de développement avec vos propres applications, placez le répertoire contenant votre clone dans le chemin d’importation Python. De ce fait, les instructions import recherchant Django vont trouver le module django de votre clone du code.

Si vous avez l’intention de travailler sur le code de Django (correction d’anomalie ou développement de fonctionnalités), vous pouvez probablement arrêter de lire cette page et passer à la documentation de contribution à Django, qui couvre des sujets comme le style de codage préféré ou sur la façon de produire et soumettre un correctif.

Les branches stables

Django utilise des branches pour préparer les nouvelles publications de Django. Chaque publication majeure possède sa propre branche stable.

Ces branches se trouvent dans le dépôt sous la forme de branches stable/A.B.x et sont créées à partir du moment où la première version alpha d’une nouvelle série est étiquetée.

Par exemple, immédiatement après que Django 1.5 alpha 1 a été produite, la branche stable/1.5.x a été créée et toute la suite de travail de préparation de code pour la version 1.5 finale a eu lieu dans celle-ci.

Ces branches sont aussi la source des versions correctives et de sécurité telles que décrites dans Versions prises en charge.

Par exemple, après la publication de Django 1.5, la branche stable/1.5.x ne reçoit plus que des corrections de sécurité ou d’anomalies jugées critiques pour sa stabilité, qui sont alors publiées comme Django 1.5.1 et ainsi de suite. La branche stable/1.4.x ne reçoit plus que des corrections de sécurité ou d’anomalies générant des pertes de données, alors que stable/1.3.x ne reçoit plus aucune mise à jour.

Information historique

Cette politique de gestion des branches stable/A.B.x a été adoptée à partir du cycle de publication de Django 1.5.

Précédemment, ces branches n’étaient créées que juste après les publications et le travail de stabilisation se faisait dans la branche principale du dépôt. De ce fait, aucun développement de nouvelle fonctionnalité pour la prochaine publication de Django ne pouvait être commité avant la publication finale en cours.

Par exemple, peu après la sortie de Django 1.3, la branche stable/1.3.x a été créée. La prise en charge officielle de cette publication a expiré et elle n’est donc plus directement maintenue par le projet Django. Cependant, cette branche et toutes les autres nommées sur le même modèle continuent d’exister, et les membres de la communautés intéressés les ont de temps à autre utilisées pour fournir du soutien non officiel pour les anciennes versions de Django.

Étiquettes (tags)

Chaque version de Django est étiquetée et signée par la personne qui a produit la version.

Les étiquettes sont accessibles sur la page tags de GitHub.

Développements de fonctionnalités archivés

Information historique

Depuis que Django a passé à Git en 2012, tout le monde peut clôner le dépôt et créer ses propres branches, ce qui rend caduque la nécessité de créer des branches officielles dans le dépôt du code source.

La section suivante est surtout utile si vous explorez l’historique du dépôt, par exemple si vous essayez de comprendre comment certaines fonctionnalités ont été développées.

Feature-development branches tend by their nature to be temporary. Some produce successful features which are merged back into Django’s main branch to become part of an official release, but others do not; in either case, there comes a time when the branch is no longer being actively worked on by any developer. At this point the branch is considered closed.

Django used to be maintained with the Subversion revision control system, that has no standard way of indicating this. As a workaround, branches of Django which are closed and no longer maintained were moved into attic.

A number of tags exist under the archive/ prefix to maintain a reference to this and other work of historical interest.

Les tags suivants sous le préfixe archive/attic/ font référence au point le plus récent des branches dont le code a finalement été intégré dans la branche principale de Django :

• boulder-oracle-sprint`: ajout de la prise en charge des bases de données Oracle dans l’ORM (object-relational mapper) de Django. Ceci a fait partie de Django dès sa version 1.0.
• gis: ajout de la prise en charge des requêtes géographiques/spatiales par l’ORM de Django. Ceci a fait partie de Django dès sa version 1.0, dans l’application intégrée django.contrib.gis.
• i18n: ajout de la prise en charge de l’internationalisation dans Django. Ceci a fait partie de Django dès sa version 0.90.
• magic-removal`: une refonte majeure des API internes et publiques de l’ORM (object-relational mapper) de Django. Ceci a fait partie de Django dès sa version 0.95.
• multi-auth: A refactoring of Django’s bundled authentication framework which added support for authentication backends. This has been part of Django since the 0.95 release.
• new-admin: A refactoring of Django’s bundled administrative application. This became part of Django as of the 0.91 release, but was superseded by another refactoring (see next listing) prior to the Django 1.0 release.
• newforms-admin: The second refactoring of Django’s bundled administrative application. This became part of Django as of the 1.0 release, and is the basis of the current incarnation of django.contrib.admin.
• queryset-refactor: A refactoring of the internals of Django’s object-relational mapper. This became part of Django as of the 1.0 release.
• unicode: A refactoring of Django’s internals to consistently use Unicode-based strings in most places within Django and Django applications. This became part of Django as of the 1.0 release.

Additionally, the following tags under the archive/attic/ prefix reference the tips of branches that were closed, but whose code was never merged into Django, and the features they aimed to implement were never finished:

• full-history
• generic-auth
• multiple-db-support
• per-object-permissions
• schema-evolution
• schema-evolution-ng
• search-api
• sqlalchemy

Finally, under the archive/ prefix, the repository contains soc20XX/<project> tags referencing the tip of branches that were used by students who worked on Django during the 2009 and 2010 Google Summer of Code programs.