gwift-book/source/intro/01-prerequisites.rst

174 lines
7.3 KiB
ReStructuredText
Raw Normal View History

2015-11-06 12:13:23 +01:00
*************
Environnement
*************
2015-09-29 16:05:46 +02:00
2015-10-02 15:01:29 +02:00
Avant de démarrer le développement, il est nécessaire de passer un peu de temps sur la configuration de l'environnement.
2015-10-21 21:56:32 +02:00
Les morceaux de code seront développés pour Python3.4+ et Django 1.8+. Ils nécessiteront peut-être quelques adaptations pour fonctionner sur une version antérieure.
2015-09-29 16:05:46 +02:00
2016-05-31 20:50:06 +02:00
**Remarque** : les commandes qui seront exécutés dans ce livre le seront depuis un shell sous GNU/Linux. Certaines devront donc être adaptées si vous êtes dans un autre environnemnet.
2015-10-02 15:01:29 +02:00
2016-01-05 13:59:29 +01:00
Virtualenv
==========
2016-01-07 09:53:34 +01:00
Nous allons utiliser ``virtualenv`` afin de créer un `environnement virtuel <http://sametmax.com/les-environnement-virtuels-python-virtualenv-et-virtualenvwrapper/>`_ pour python et ``virtualenvwrapper`` pour en faciliter la gestion, et les prérequis seront remplis.
2015-10-14 08:52:57 +02:00
2016-01-07 09:53:34 +01:00
Suivant votre distribution, il sera sans doute nécessaire d'éditer le fichier ``~/.bashrc`` (ou tout fichier lancé au démarrage de votre session) et de vérifier que la variable ``WORKON_HOME`` est bien définie et de faire un ``source`` sur le fichier ``virtualenvwrapper.sh`` (à adapter en fonction de votre distribution):
2015-10-02 15:01:29 +02:00
2015-11-06 12:13:23 +01:00
.. code-block:: shell
2015-11-22 15:09:13 +01:00
2015-11-06 12:13:23 +01:00
# ~/.bashrc
2015-10-02 15:01:29 +02:00
2015-11-06 12:13:23 +01:00
[...]
2015-09-29 16:05:46 +02:00
2015-11-06 12:13:23 +01:00
WORKON_HOME=~/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh
2015-10-14 08:52:57 +02:00
L'intérêt de ceci ? Ne pas devoir se soucier de l'emplacement des environnements virtuels, et pouvoir entièrement les découpler des sources sur lesquelles vous travaillez, en plus d'isoler le code, de créer un containeur pour les dépendances et d'être indépendant des librairies tierces déjà installées sur le système.
2015-09-29 16:05:46 +02:00
Création de l'environnement virtuel
===================================
2016-01-05 13:59:29 +01:00
Commencons par créer un environnement virtuel, afin d'y stocker les dépendances. Lancez ``mkvirtualenv gwift-env``.
2015-09-29 16:05:46 +02:00
2015-11-06 12:13:23 +01:00
.. code-block:: shell
$ mkvirtualenv -p python3 gwift-env
New python executable in gwift-env/bin/python3
Also creating executable in gwift-env/bin/python
Installing setuptools, pip...done.
2015-10-02 15:01:29 +02:00
Ceci créera l'arborescence de fichiers suivante, qui peut à nouveau être un peu différente en fonction du système d'exploitation:
2015-11-06 12:13:23 +01:00
.. code-block:: shell
2016-01-05 13:59:29 +01:00
$ ls .virtualenvs/gwift-env
bin include lib
2015-09-29 16:05:46 +02:00
Nous pouvons ensuite l'activer grâce à la commande ``workon gwift-env``.
2015-10-02 15:01:29 +02:00
2015-11-06 12:13:23 +01:00
.. code-block:: shell
2015-10-02 15:01:29 +02:00
$ workon gwift-env
2016-01-07 15:33:48 +01:00
(gwift-env)$ which python
(gwift-env)$ /home/jaguarondi/.virtualenv/gwift-env/bin/python
2016-05-31 20:50:06 +02:00
Le *shell* signale que nous sommes bien dans l'environnement ``gwift-env`` en l'affichant avant le ``$``. Par la suite, nous considérerons que l'environnement virtuel est toujours activé, même si ``gwift-env`` n'est pas présent devant chaque ``$``.
2016-05-31 20:50:06 +02:00
A présent, tous les binaires de cet environnement prendront le pas sur les binaires du système. De la même manière, une variable ``PATH`` propre est définie et utilisée, afin que les librairies Python y soient stockées. C'est donc dans cet environnement virtuel que nous retrouverons le code source de Django, ainsi que des librairies externes pour Python une fois que nous les aurons installées.
2015-11-06 12:13:23 +01:00
2016-01-07 15:33:48 +01:00
Pour désactiver l'environnement virtuel, il suffira d'utiliser la commande ``deactivate``
Création du répertoire de travail
=================================
2015-10-14 08:52:57 +02:00
2015-12-28 09:24:09 +01:00
Nous commençons par créer le répertoire du projet, à savoir ``gwift-project``.
2015-09-29 16:05:46 +02:00
2015-11-06 12:13:23 +01:00
.. code-block:: shell
2016-01-07 15:33:48 +01:00
$ mkdir gwift-project
$ cd gwift-project
Dans ce répertoire, nous pouvons rajouter les répertoires utiles à la gestion d'un projet:
.. code-block:: shell
2016-01-07 15:33:48 +01:00
$ mkdir docs requirements
$ touch docs/README.md
Création du projet Django
=========================
2015-09-29 16:05:46 +02:00
2015-10-02 15:01:29 +02:00
Comme l'environnement est activé, on peut à présent y installer Django. La librairie restera indépendante du reste du système, et ne polluera pas les autres projets.
2015-12-28 09:24:09 +01:00
C'est parti: ``pip install django``!
2015-11-06 12:13:23 +01:00
.. code-block:: shell
2016-01-07 15:33:48 +01:00
$ pip install django
2015-11-06 12:13:23 +01:00
Collecting django
Downloading Django-1.8.4-py2.py3-none-any.whl (6.2MB)
100% |################################| 6.2MB 91kB/s eta 0:00:01
Installing collected packages: django
Successfully installed django-1.8.4
2015-12-28 09:24:09 +01:00
Les commandes de création d'un nouveau site sont à présent disponibles, la principale étant ``django-admin startproject``. Par la suite, nous utiliserons ``manage.py``, qui constitue un *wrapper* autour de `django-admin`.
Pour démarrer notre projet, nous lançons donc ``django-admin startproject gwift``.
2015-11-06 12:13:23 +01:00
.. code-block:: shell
2016-01-07 15:33:48 +01:00
$ django-admin startproject gwift
2015-10-02 15:01:29 +02:00
Cette action a pour effet de créer un nouveau dossier ``gwift``, dans lequel on trouve la structure suivante:
2015-10-02 15:01:29 +02:00
2015-11-06 12:13:23 +01:00
.. code-block:: shell
2015-10-02 15:01:29 +02:00
2016-01-07 15:33:48 +01:00
$ tree gwift
2015-11-06 12:13:23 +01:00
gwift
├── gwift
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py
2015-11-06 12:13:23 +01:00
2016-05-31 20:50:06 +02:00
Si vous le souhaitez, et pour plus de clarté, renommez le premier dossier ``gwift`` en ``src``, par exemple: cela évitera d'avoir une structure hiérarchique type ``gwift-project/gwift/gwift``, mais plutôt quelque chose comme ``gwift-project/src/gwift``, sur le modèle ``{projet}/{sources}/{application}``. On a à présent:
.. code-block:: shell
$ tree src
src
├── gwift
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py
2015-11-22 15:09:13 +01:00
Chacun de ces fichiers sert à:
2015-11-22 15:09:13 +01:00
* ``settings.py`` contient tous les paramètres globaux à notre projet.
* ``urls.py`` contient les variables de routes, les adresses utilisées et les fonctions vers lesquelles elles pointent.
* ``manage.py``, pour toutes les commandes de gestion.
* ``wsgi.py`` contient la définition de l'interface `WSGI <https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface>`_, qui permettra à votre serveur Web (Nginx, Apache, ...) de faire un pont vers votre projet.
2015-10-01 20:51:17 +02:00
2015-10-02 15:01:29 +02:00
Gestion des dépendances
2015-11-06 12:13:23 +01:00
=======================
2015-10-02 15:01:29 +02:00
2016-05-31 20:50:06 +02:00
Comme nous venons d'ajouter une dépendance à notre projet, nous allons créer un fichier reprenant tous les dépendances de notre projet. Celles-ci sont normalement placées dans un fichier ``requirements.txt``. Dans un premier temps, ce fichier peut être placé directement à la racine du projet, mais on préférera rapidement le déplacer dans un sous-répertoire spécifique (``requirements``), afin de grouper les dépendances en fonction de leur utilité:
2015-10-01 20:51:17 +02:00
2015-12-28 09:24:09 +01:00
* ``base.txt``
* ``dev.txt``
* ``staging.txt``
* ``production.txt``
2015-10-01 20:51:17 +02:00
2015-12-28 09:24:09 +01:00
Au début de chaque fichier, il suffira d'ajouter la ligne ``-r base.txt``, puis de lancer l'installation grâce à un ``pip install -r <nom du fichier>``. De cette manière, il est tout à fait acceptable de n'installer `flake8` et `django-debug-toolbar` qu'en développement par exemple. Dans l'immédiat, ajoutez simplement ``django`` dans le fichier ``requirements/base.txt``.
2015-10-02 15:01:29 +02:00
2015-11-06 12:13:23 +01:00
.. code-block:: shell
2016-01-07 15:33:48 +01:00
$ echo django >> requirements/base.txt
Structure finale de l'environnement
===================================
Nous avons donc la strucutre finale pour notre environnement de travail:
.. code-block:: shell
2016-01-07 15:33:48 +01:00
$ tree ~/gwift-project
gwift-project/
├── docs
│   └── README.md
2016-05-31 20:50:06 +02:00
├── src
│   ├── gwift
│   │ ├── __init__.py
│   │ ├── settings.py
│   │ ├── urls.py
│   │ └── wsgi.py
│   └── manage.py
└── requirements
└── base.txt