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.

Les branches de développement de fonctionnalités sont par nature temporaires. Certaines apportent des fonctionnalités abouties qui sont finalement fusionnées dans la branche principale de Django pour faire partie d’une publication officielle, alors que d’autres ne le seront jamais. Dans tous les cas, il arrive un moment où la branche n’est plus activement développée par personne. À ce moment-là, la branche est considérée comme fermée.

Django était par le passé développé en utilisant le système de gestion de versions Subversion, qui ne possède pas de manière standard de signifier cela. C’est pourquoi ces branches terminées de Django qui ne sont plus maintenues ont été déplacées dans attic.

Un certain nombre d’étiquettes existent sous le préfixe archive/ pour maintenir des références à ces branches et à d’autres travaux d’intérêt historique.

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: une refactorisation de l’infrastructure d’authentification intégrée à Django qui ajouta la prise en charge des moteurs d’authentification. Ces travaux ont été intégrés à Django dès sa version 0.95.

• new-admin: une refactorisation de l’application d’administration de Django. Ces travaux furent intégrés dans la version 0.91 de Django, mais d’autres travaux similaires l’ont remplacée (voir ci-après) avant la version 1.0 de Django.

• newforms-admin: la deuxième refonte de l’application d’administration livrée avec Django. Elle a été intégrée dans Django dès sa version 1.0, et constitue la base de l’incarnation actuelle de django.contrib.admin.

• queryset-refactor: une refonte de la structure interne du mapping objet-relationnel de Django. Elle a été intégrée dans Django dès sa version 1.0.

• unicode: une refonte de la structure interne de Django pour utiliser des chaînes basées sur Unicode de manière cohérente dans la plupart du code de Django et de ses applications. Elle a été intégrée dans Django dès sa version 1.0.

De plus, les étiquettes suivantes sous le préfixe archive/attic/ font référence au sommet de branches qui ont été fermées mais dont le code n’a jamais été intégré dans Django, et dont les fonctionnalités qu’elles visaient à développer n’ont jamais été terminées :

• full-history

• generic-auth

• multiple-db-support

• per-object-permissions

• schema-evolution

• schema-evolution-ng

• search-api

• sqlalchemy

Pour terminer, sous le préfixe archive/, le dépôt contient les étiquettes soc20XX/<project> référençant le sommet de branches utilisées par des étudiants ayant travaillé sur Django durant les programmes «Google Summer of Code» de 2009 et 2010.