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:
maincontains the main in-development code which will become the next packaged release of Django. This is where most development activity is focused.stable/A.B.xsont 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.
The main branch¶
If you’d like to try out the in-development code for the next release of Django, or if you’d like to contribute to Django by fixing bugs or developing new features, you’ll want to get the code from the main branch.
Note
Prior to March 2021, the main branch was called 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.
For example, shortly after the release of Django 1.3 the branch
stable/1.3.x was created. Official support for that release has expired,
and so it no longer receives direct maintenance from the Django project.
However, that and all other similarly named branches continue to exist, and
interested community members have occasionally used them to provide
unofficial support for old Django releases.
É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.
The following tags under the archive/attic/ prefix reference the tip of
branches whose code eventually became part of Django itself:
boulder-oracle-sprint: Added support for Oracle databases to Django’s object-relational mapper. This has been part of Django since the 1.0 release.gis: Added support for geographic/spatial queries to Django’s object-relational mapper. This has been part of Django since the 1.0 release, as the bundled applicationdjango.contrib.gis.i18n: Added internationalization support to Django. This has been part of Django since the 0.90 release.magic-removal: A major refactoring of both the internals and public APIs of Django’s object-relational mapper. This has been part of Django since the 0.95 release.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 ofdjango.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-historygeneric-authmultiple-db-supportper-object-permissionsschema-evolutionschema-evolution-ngsearch-apisqlalchemy
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.
