gwift-book/source/part-1-workspace/django/_index.adoc

Un projet Django

Travailler en isolation

On va aborder la gestion et l’isolation des dépendances. Il est tout à fait possible de s’en passer complètement dans le cadre de "petits" projets ou d’applications déployées sur des machines dédiées, et de fonctionner à grand renforts de "sudo" et d’installation globale des dépendances.

Cette section est aussi utile pour une personne travaillant seule, que pour transmettre les connaissances à un nouveau membre de l’équipe ou pour déployer l’application elle-même.

Cette pratique est cependant fortement déconseillée pour plusieurs raisons:

1. Il est tout à fait envisagable que deux applications différentes soient déployées sur un même hôte, et nécessitent chacune deux versions différentes d’une même dépendance.

2. Pour la reproductibilité d’un environnement spécifique. Cela évite notamment les réponses type "Ca juste marche chez moi", puisque la construction d’un nouvel environnement fait partie intégrante du processus de construction et de la documentation du projet; grace à elle, on a la possibilité de construire un environnement sain et d’appliquer des dépendances identiques, quelle que soit la machine hôte.

image::images/it-works-on-my-machine.jpg

Depuis la version 3.5 de Python, le module venv est recommandé afin de créer un environnement virtuel.

Il existe plusieurs autres modules permettant d’arriver au même résultat, avec quelques avantages et inconvénients pour chacun d’entre eux.

Note	parler ici de poetry, pip, pipenv et rebondir sur le point 2 des 12 facteurs.

Comme on l’a vu ci-dessus, django-admin permet de créer un nouveau projet. On fait ici une distinction entre un projet et une application:

• Projet: ensemble des applications, paramètres, pages HTML, middlwares, dépendances, etc., qui font que votre code fait ce qu’il est sensé faire.

• Application: contexte éventuellement indépendant, permettant d’effectuer une partie isolée de ce que l’on veut faire.

Pour gwift, on va notamment avoir

1. une première application pour la gestion des listes de souhaits et des éléments,

2. une deuxième application pour la gestion des utilisateurs,

3. voire une troisième application qui gérera les partages entre utilisateurs et listes.

On voit bien ici le principe de contexte: l’application viendra avec son modèle, ses tests, ses vues et son paramétrage. Elle pourra éventuellement être réutilisée dans un autre projet. C’est en ça que consistent les paquets Django déjà disponibles: ce sont simplement de petites applications empaquetées pour être réutilisées (eg. Django-Rest-Framework, Django-Debug-Toolbar, …​).

Note	analyser la structure de ces paquets et comparer avec la structure finale de l’environnement.

Gestion

Comme expliqué un peu plus haut, le fichier manage.py est un wrapper sur les commandes django-admin. A partir de maintenant, nous n’utiliserons plus que celui-là pour tout ce qui touchera à la gestion de notre projet:

• manage.py check pour vérifier (en surface…​) que votre projet ne rencontre aucune erreur

• manage.py check --deploy, pour vérifier (en surface aussi) que l’application est prête pour un déploiement.

• manage.py runserver pour lancer un serveur de développement

• manage.py test pour découvrir les tests unitaires disponibles et les lancer.

La liste complète peut être affichée avec manage.py help. Vous remarquerez que ces commandes sont groupées selon différentes catégories:

• auth: création d’un nouveau super-utilisateur, changer le mot de passe pour un utilisateur existant.

• django: vérifier la compliance du projet, lancer un shell, dumper les données de la base, effectuer une migration du schéma, …​

• sessions: suppressions des sessions en cours

• staticfiles: gestion des fichiers statiques et lancement du serveur de développement.

Nous verrons plus tard comment ajouter de nouvelles commandes.

Structure d’une application

Maintenant que l’on a vu à quoi servait manage.py, on peut créer notre nouvelle application grâce à la commande manage.py startapp <label>.

Cette application servira à structurer les listes de souhaits, les éléments qui les composent et les parties que chaque utilisateur pourra offrir. Essayez de trouver un nom éloquent, court et qui résume bien ce que fait l’application. Pour nous, ce sera donc wish. C’est parti pour manage.py startapp wish!

$ python manage.py startapp wish

Résultat? Django nous a créé un répertoire wish, dans lequel on trouve les fichiers et dossiers suivants:

• wish/admin.py servira à structurer l’administration de notre application. Chaque information peut en effet être administrée facilement au travers d’une interface générée à la volée par le framework. On y reviendra par la suite.

• wish/init.py pour que notre répertoire wish soit converti en package Python.

• wish/migrations/, dossier dans lequel seront stockées toutes les différentes migrations de notre application.

• wish/models.py pour représenter et structurer nos données.

• wish/tests.py pour les tests unitaires.

Par soucis de clarté, déplacez ce nouveau répertoire wish dans votre répertoire gwift existant. C’est une forme de convention. La structure de vos répertoires devient celle-ci:

(gwift-env) fred@aerys:~/Sources/gwift$ tree .
.
├── docs
│   └── README.md
├── gwift
│   ├── asgi.py
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   ├── wish (1)
│   │   ├── admin.py
│   │   ├── apps.py
│   │   ├── __init__.py
│   │   ├── migrations
│   │   │   └── __init__.py
│   │   ├── models.py
│   │   ├── tests.py
│   │   └── views.py
│   └── wsgi.py
├── Makefile
├── manage.py
├── requirements
│   ├── base.txt
│   ├── dev.txt
│   └── prod.txt
├── setup.cfg
└── tox.ini

6 directories, 22 files

1. Notre application a bien été créée, et on l’a déplacée dans le répertoire gwift !

   • admin.py servira à structurer l’administration de notre application. Chaque information peut en effet être administrée facilement au travers d’une interface générée à la volée par le framework. On y reviendra par la suite.

   • init.py pour que notre répertoire wish soit converti en package Python.

   • migrations/, dossier dans lequel seront stockées toutes les différentes migrations de notre application.

   • models.py pour représenter et structurer nos données.

   • tests.py pour les tests unitaires.

Migrations et schéma de bases de données

reset migrations.

En gros, soit on supprime toutes les migrations (en conservant le fichier __init__.py), soit on
réinitialise proprement les migrations avec un --fake-initial (sous réserve que toutes les personnes qui
utilisent déjà le projet s'y conforment... Ce qui n'est pas gagné.

Tests unitaires

Plein de trucs à compléter ici ;-) Est-ce qu’on passe par pytest ou par le framework intégré ? Quels sont les avantages de l’un % à l’autre ? * views.py pour définir ce que nous pouvons faire avec nos données.

Note	vérifier s’il s’agit bien d’une forme de convention :-p

Note	Vérifier aussi comment les applications sont construites. Type DRF, Django Social Auth, tout ça.