Installer Django, mettre en place l’environnement de dev

Première étape pour atteindre l’objectif que je me suis fixé: installer un environnement de développement.

Virtualenv : comment Python cloisonne votre application

En découvrant cet outil, je pensais que c’était une vagrant like, mais ce n’est pas le cas. Si je comprends bien, il ne se charge que de virtualiser du python, ce qui représente un gain en performance non négligeable. Il permet d’avoir plusieurs applications sur la même machine, sans partager les librairies et leurs versions, et sans avoir à toucher à l’environnement global du host, et sans partager les process.

pip étant le gestionnaire de paquet pour python, installons virtualenv :


pip install virtualenv

John van Hulsen - CC by-nc-nd
John van Hulsen – CC by-nc-nd

Maintenant, on peut lancer virtualenv chemin/vers/projet et ça va créer les fichiers et exécutables pour isoler votre application.

La doc de virtualenv conseille de lancer source bin/activate, mais à mon avis, quand vous créez le projet, il est plus utile d’ajouter chemin/vers/projet/bin à votre PATH. On verra plus tard, pour l’instant on fait ce que dit la doc.

Préparer Django

On reste donc dans le dossier de notre environnement fraîchement créé, et là, rien de plus simple :

pip install django

6Mo pour un framework web, c’est quand même très léger.

On vérifie que tout s’est bien passé, et on va créer notre projet Django :

python -m django --version
1.9.8

django-admin startproject helloworld
cd helloworld/

Pour avoir un serveur web de base et tester l’appli, il faut lancer :

python manage.py runserver

Il y a un message d’erreur au sujet des migrations, mais il semble que pour l’instant, il faille l’ignorer; Ca concerne la base de donnée, mais rien n’est prêt pour l’instant de ce côté.

En allant sur 127.0.0.1:8000 on a un beau message :

It worked!
Congratulations on your first Django-powered page.

Je vais tout de suite faire un alias pyserv= »python manage.py runserver » pour ne pas lancer cette commande systématiquement.

La différence entre les projets, et les apps

Ca reste un peu abstrait pour l’instant. En gros, les Projets correspondent vulgairement à ce qu’on mets juste avant un DocumentRoot, et les Apps sont toutes les entités/models qui vont être utilisé dans le projet (articles, commentaires, etc). Il y a ensuite les Modules, qui correspondent par exemple aux dossiers Services, Console, Events, etc. Donc un projet contient (vulgairement) autant d’apps qu’il n’y a de models, mais aussi des modules.

Pour créer une app dans un projet, on lance :

python manage.py startapp articles

Là un nouveau dossier contenant les fichiers de base, pour le modèle, les vues, les migrations pour la base de données, etc.
On peut directement créer un fichier urls.py dedans, contenant toutes les urls spécifiques à cette app. L’idée de faire des includes partout dans le fichier urls.py du projet me repousse un peu pour l’instant, pour la lisibilité, mais on dirait que c’est la pratique.

Le Hello World

Maintenant qu’on connait un peu la structure, on va aller modifier le fichier de routes (urls.py) pour inclure le fichier de urls.py de l’app articles (sic), et modifier le fichiers views.py dans le dossier articles.

from django.shortcuts import render
from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello World")

Vu d’ici, on dirait plus un controller qu’un fichier de vue, mais on verra la suite plus tard.

Il faut ensuite relancer le pyserv, vu qu’on a créé des nouveaux fichiers, et aller sur localhost:8000/articles.

Pour l’instant c’est très appréciable.  L’auto-complétion de Sublime Texte est infiniment plus efficace sur ce langage que sur PHP, c’est appréciable. Coder du Python, dans un logiciel codé en Python…

Recherches utilisées pour trouver cet article :mettre en place un framework django
metrogeek

Comments 1

Laisser un commentaire