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.
\nCependant, 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.
\nCe 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.
\nLe 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.
\nLe 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.
\nLe dépôt Git comprend plusieurs branches:
\nmaster 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.
\nUn 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.
\nmasterLien vers cette rubrique#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 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.
\nDjango utilise des branches pour préparer les nouvelles publications de Django. Chaque publication majeure possède sa propre branche stable.
\nCes 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.
\nPar 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.
tags)Lien vers cette rubrique#Chaque version de Django est étiquetée et signée par la personne qui a produit la version.
\nLes étiquettes sont accessibles sur la page tags de GitHub.
\nFeature-development branches tend by their nature to be temporary. Some\nproduce successful features which are merged back into Django’s master to\nbecome part of an official release, but others do not; in either case, there\ncomes a time when the branch is no longer being actively worked on by any\ndeveloper. At this point the branch is considered closed.
\nDjango used to be maintained with the Subversion revision control system, that\nhas no standard way of indicating this. As a workaround, branches of Django\nwhich are closed and no longer maintained were moved into attic.
A number of tags exist under the archive/ prefix to maintain a reference to\nthis and other work of historical interest.
The following tags under the archive/attic/ prefix reference the tip of\nbranches whose code eventually became part of Django itself:
boulder-oracle-sprint: Added support for Oracle databases to\nDjango’s object-relational mapper. This has been part of Django\nsince the 1.0 release.
gis: Added support for geographic/spatial queries to Django’s\nobject-relational mapper. This has been part of Django since the 1.0\nrelease, as the bundled application django.contrib.gis.
i18n: Added internationalization support to\nDjango. This has been part of Django since the 0.90 release.
magic-removal: A major refactoring of both the internals and\npublic APIs of Django’s object-relational mapper. This has been part\nof Django since the 0.95 release.
multi-auth: A refactoring of Django’s bundled\nauthentication framework which added support for\nauthentication backends. This has\nbeen part of Django since the 0.95 release.
new-admin: A refactoring of Django’s bundled\nadministrative application. This became part of\nDjango as of the 0.91 release, but was superseded by another\nrefactoring (see next listing) prior to the Django 1.0 release.
newforms-admin: The second refactoring of Django’s bundled\nadministrative application. This became part of Django as of the 1.0\nrelease, and is the basis of the current incarnation of\ndjango.contrib.admin.
queryset-refactor: A refactoring of the internals of Django’s\nobject-relational mapper. This became part of Django as of the 1.0\nrelease.
unicode: A refactoring of Django’s internals to consistently use\nUnicode-based strings in most places within Django and Django\napplications. This became part of Django as of the 1.0 release.
Additionally, the following tags under the archive/attic/ prefix reference\nthe tips of branches that were closed, but whose code was never merged into\nDjango, 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\nsoc20XX/<project> tags referencing the tip of branches that were used by\nstudents who worked on Django during the 2009 and 2010 Google Summer of Code\nprograms.