Editions ENI Livres | Vidéos | e-Formations
Installation
Introduction
Django est une infrastructure logicielle très fournie, mais ce n’est pas un produit autosuffisant, dans le sens où, étant écrit en langage Python, il s’appuie sur l’existence préalable d’un interpréteur de ce langage sur la machine. Il faut donc installer cet interpréteur comme un prérequis.
Django a besoin d’un gestionnaire de base de données, ne serait-ce que pour son fonctionnement interne. Le gestionnaire SQLite fait partie de la liste des gestionnaires supportés et Python en contient une implémentation. Il est possible de le constater par la présence, sous le répertoire d’installation de Python, de : DLLs\sqlite3.dll et Lib\sqlite3\.
Comme son nom l’indique, ce gestionnaire se veut léger, c’est à la fois sa force (il est courant dans l’informatique embarquée, Android par exemple) et sa faiblesse (il a des limites en fonctionnalités et en performances). Autre effet de la légèreté, il n’existe pas d’outil officiel si l’on veut s’épargner les manipulations en ligne de commande (et la connaissance de la syntaxe SQL) par l’utilisation d’une interface graphique. Il faut chercher parmi les outils de la communauté, dont beaucoup ont leur développement abandonné depuis de nombreuses années. Pour la construction...
Installation de Python
Pour installer Python, rendez-vous tout d’abord à l’adresse : https://www.python.org/downloads/
1. Python 2 ou 3 ?
La série Python 3, le successeur de Python 2, est apparue fin 2008. En raison des changements non rétrocompatibles, Django est resté pendant longtemps lié à la série Python 2. Publiée début 2013, Django 1.5 a été la première version à introduire un fonctionnement possible sous Python 3 tout en continuant à fonctionner aussi en Python 2, avec la même base de code, car les concepteurs ont fait le choix d’une transition progressive plutôt qu’un saut incompatible. Une forte raison en faveur de cette stratégie provient de l’importance incontournable des applications communautaires qui viennent enrichir l’infrastructure logicielle et qui étaient amenées par nature à avoir chacune leur rythme et leur stratégie de migration.
La série Django 1.11 est la dernière à tourner sous Python 2. Fin 2017, la série Django 2 marque une rupture par son numéro majeur de version, mais ce n’est pas en raison d’une quantité inhabituelle de changements non rétrocompatibles. Il s’agit plutôt de symboliser deux événements marquants : d’une part, l’abandon du support de Python 2, avec l’allègement en conséquence de la base de code et, d’autre part, l’adoption d’un nouveau schéma de numérotation, inspiré par le concept de gestion sémantique de version.
Pendant cette phase de transition de Python, il suffisait qu’un paquet additionnel ne soit pas encore mis à niveau pour être le grain de sable qui empêche les montées de version de Django dans son projet. Django 1.11 est estampillée LTS (Long Term Support) signifiant qu’elle bénéficie d’un support à long terme, qui s’étend jusqu’en avril 2020 au moins.
Étant donné la quantité de paquets additionnels écrits pour l’infrastructure logicielle, il est inévitable, au cours de recherches, de tomber sur des paquets qui n’ont pas été adaptés à l’évolution. Il reste d’actualité...
Installation d’un moteur de base de données
Django supporte officiellement les systèmes suivants : PostgreSQL, MySQL, Oracle et SQLite. Il est possible de trouver des paquets implémentant l’accès à d’autres moteurs, mais ce sont des initiatives d’individus ou d’organisations à part, qui ont donc chacune leur pérennité, leur couverture de fonctionnalités et leur support des versions de Django. Bien sûr, toute question relative à leur support doit être adressée à ces intervenants externes.
Comme annoncé dans l’introduction, il va dès à présent être mis en place un gestionnaire de base de données, plus étoffé que le SQLite déjà présent dans la distribution Python.
Quel que soit le choix, il est plus sûr d’employer en environnement de développement le moteur qui sera utilisé en environnement de production, peu importe les considérations de confort ou d’outillage.
Pour le projet, le choix arbitraire de PostgreSQL est fait, sans pour autant avoir d’arguments forts de préférence par rapport aux autres possibilités.
1. Installation de PostgreSQL
Rendez-vous sur le site : https://www.postgresql.org/download/
En suivant le lien dédié à la distribution binaire pour Windows, il est proposé une liste d’installateurs. Faisons ici le choix de Interactive installer by EnterpriseDB, qui inclut l’outil graphique d’administration pgAdmin.
Le déroulé ci-dessous a été réalisé avec :
postgresql-11.1-1-windows-x64.exe Si vous avez déjà...
Installation d’un outillage pour traduction
Au stade consacré à l’internationalisation, il sera nécessaire de mettre en œuvre des outils dédiés à la gestion de la déclinaison des chaînes de caractères en plusieurs langues. Django dispose d’une commande pour collecter ces chaînes et les rassembler dans un fichier de messages. Le fichier répond à un format reconnu, établi par des outils à code source ouvert qui prennent aussi en charge d’autres étapes du processus.
La traduction du contenu du fichier se réalise à part, indépendamment de l’infrastructure logicielle, soit de façon manuelle (simple éditeur de texte), soit avec des outils spécialisés ou des plateformes de services.
La dernière étape consiste à compiler chacun des fichiers de messages, pour que le serveur utilise un format optimisé, meilleur pour ses performances.
Les opérations de collecte et de compilation sont orchestrées par l’infrastructure logicielle. Celle-ci s’appuie pour cela sur l’outillage GNU gettext. Contrairement à d’autres OS, cette suite d’outils n’est pas disponible dans Windows, il est nécessaire de procéder à son installation.
La documentation Django ne donne pas de directives quant au choix du dépôt...
Installation d’un gestionnaire de fuseaux horaires
Le paquet pytz (comprendre PYthon TimeZone) est une dépendance requise par Django. Son installation sera initiée par celle de Django si le paquet n’est pas présent. On pourrait donc se passer de cette étape manuelle. Elle va toutefois être réalisée volontairement, pour son effet didactique.
Ce paquet apporte le support des fuseaux horaires pour les manipulations de dates et heures locales. Il s’appuie sur la base de données Olson des fuseaux horaires.
Django a fait ce choix, mais il existe d’autres gestionnaires. Par exemple, la documentation Python recommande le paquet dateutil.tz.
Passez la commande d’installation :
D:\>\Python37\Scripts\pip install --no-compile pytz
Collecting pytz
Downloading https://files.pythonhosted.org/packages/61/28/[...]
[...]/pytz-2018.9-py2.py3-none-any.whl (510kB)
Installing collected packages: pytz
Successfully installed pytz-2018.9 La liste des apports est :
D:\>dir \Python37\Lib\site-packages\py*
<DIR> pytz
<DIR> pytz-2018.9.dist-info Installation de Django
Des versions anciennes de la documentation officielle contenaient, sur le sujet de l’installation, une section traitant du retrait préalable d’une éventuelle installation précédente. Elle était justifiée par le besoin d’une intervention manuelle d’effacement dans le cas précis d’une installation elle aussi manuelle, c’est-à-dire sans passer par un outil spécifique. Cette section n’apparaît désormais plus, puisque seul l’usage de l’outil pip est recommandé et celui-ci sait gérer proprement une installation par-dessus une version déjà présente. Dans tous les cas, au final, une action d’installation est censée supplanter un exemplaire déjà présent.
Dans ce chapitre dédié aux installations, il est supposé que les produits ne sont pas déjà présents sur le poste de travail ou qu’il n’y a aucune conséquence à remplacer une installation préexistante. S’agissant de l’infrastructure logicielle, il est pourtant assez courant de vouloir confronter son travail et ses dépendances à plus qu’une version, au moins durant une période de transition, pour vérifier la continuité de fonctionnement. Ce cas spécifique est abordé au chapitre...