Python : configuration sur Windows et outillage#

Date de publication initiale : 19 juin 2020

Mots-clés : Python | Windows | Développement

Je travaille beaucoup avec Python sur Windows depuis quelques années. En comparaison avec des distributions Linux comme Debian où l'interpréteur est intégré au système (ce qui peut poser d'autres problèmes), cela a toujours été plus compliqué de se faire un environnement de travail confortable. Avec le changement de braquet de la firme de Redmond par rapport à l'open source, les choses se sont grandement améliorées ces dernières années.

Ceci dit, cela fait toujours du bien de se noter quelque part les méthodes et étapes à ne pas oublier pour être rapidement confortable et efficace. Et, qui sait, en partageant, ça servira peut-être à quelqu'un et j'apprendrai des éventuels retours .

Installation et configuration#

Modalités#

Sur Windows, Python peut être installé de plusieurs manières :

• via les installateurs traditionnels : ça reste la meilleure option d'après moi
• via Chocolatey avec un simple choco install python
• via le Windows Store : pratique pour le déployer chez des utilisateurs mais il y a certaines limites bloquantes pour les usages avancés
• via conda : un peu bourrin mais très pratique lorsque l'on travaille sur des thématiques de traitement scientifique
• via nuget
• bientôt via winget : winget install python

Activer les chemins de fichiers longs#

Cette limitation de longueur de chemin a longtemps complexifié les développements et rendu fou/lles quelques développeur/ses (bon et, soyons bon joueur, aussi forcé les utilisateurs à une certaine forme de bonne pratique dans le nommage) !

Désormais c'est assez facile de réduire le risque d'AVC :

• soit en cochant l’option dans l’installateur Python
• soit en suivant cette procédure (ou ici)

Ajouter Python au PATH#

De même, c'est désormais très bien géré :

• soit en cochant l’option dans l’installateur Python
• soit en ajoutant manuellement les chemins vers le dossier d'installation et le sous-dossier Scripts

Lorsque plusieurs versions sont installées, utiliser le lanceur.

Autoriser l’utilisation des environnements virtuels#

Les environnements virtuels utilisent des scripts que Windows demande d'autoriser spécifiquement. Ouvrir Powershell en mode admin et entrer :

1

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Autoriser Python à accéder au système de fichiers#

Dans les configurations récentes de Windows 10, la politique de sécurité est parfois configurée pour filtrer l'accès au système de fichiers notamment pour limiter les attaques par rançongiciels (ransomwares).

Lors des premières utilisations, il est donc parfois nécessaire d'autoriser Python à accéder au système de fichiers sur l'appareil, via le centre de sécurité :

Bonnes habitudes et astuces#

Utiliser Powershell#

Cela peut paraître évident mais ça va mieux en le disant : il faut arrêter avec cmd et utiliser Powershell. Sauf cas spécifiques (dont l'OSGeo4W...), il faut oublier cmd et configurer le système pour utiliser Powershell par défaut. Pourquoi ? Mais parce-que :

• cmd ne tient pas compte de toutes les subtilités apportées par les versions récentes du système (encodage, chemins, etc.)
• certaines commandes bash sont prises en compte : ls, rm, mkdir...
• les chemins de dossiers et fichiers sont bien interprétés, quel que soit le séparateur utilisé : / ou \
• des fonctionnalités désormais basiques : autocomplétion, modules, coloration, etc.

Et puis on ne peut décemment pas utiliser un outil daté au carbone 14 et s'en servir pour pester contre le système d'exploitation. Donc utiliser Powershell permet de râler en toute honnêteté (la bonne foi n'est jamais obligatoire) sur Windows. Et il ne faut pas s'inquiéter, après ça il reste encore largement de quoi critiquer !

Utiliser le launcher#

L'installation de plusieurs versions de Python finit toujours par arriver, notamment pour s'adapter aux différentes intégrations logicielles.

S'il est bien sûr possible de créer des profils pour Powershell à la manière d'un .bashrc, le lanceur intégré lors de l'installation de Python permet de gérer facilement les différentes versions. Un peu à la manière d'un update-alternatives mais, à mon sens en tout cas, avec une meilleure flexibilité à l'usage.

Par exemple :

Lister les versions installées :

1
2
3
4

PS C:\Users\ingeoveritas> py --list
Installed Pythons found by C:\WINDOWS\py.exe Launcher for Windows
 -3.8-64 *
 -3.7-64

Mettre à jour pip pour une version de Python en particulier :

1

py -3.7 -m pip install -U pip

Environnements virtuels#

Les environnements virtuels (virtual environment) sont un des fondamentaux du développement en Python, car ils permettent de garantir l'isolation des dépendances (et leurs versions) entre les différents projets.

Tout développement, sur un projet nouveau ou existant, commence donc plus ou moins ar ces commandes :

1
2
3
4
5
6
7
8

# créer l'environnement virtuel
py -3.7 -m venv .venv
# l'activer / y entrer
.venv/Scripts/activate
# MAJ pip, setuptools et wheel
python -m pip install -U pip setuptools wheel
# installer les prérequis
python -m pip install -U -r .\requirements.txt

Pour le développement d'un package, installer le projet en cours en mode éditable (voir documentation officielle)) :

1

python -m pip install -e .

Documentation in-code#

Python est un langage qui se documente facilement avec les docstrings, utilisables par d'autres outils : logiciels de développement, génération de documentation en ligne (HTML) ou statique (PDF), etc.

Personnellement, j'utilise Visual Studio Code et l'extension Python Docstring Generator qui permet de générer automatiquement une structure type de docstring à partir du code.

Par défaut, elle implémente certaines conventions mais il est possible de personnaliser la structure avec un fichier docstring-config.mustache (généralement stocké dans le dossier .vscode) :

Voir le fichier de template mustache que j'utilise pour El Géo Paso.

Tests#

En Python, le code est généralement assez simple à tester, compte-tenu de l'orientation serveur / objet / fonctionnel du langage.

Les fichiers de tests sont :

• préfixés par le mot test
• stockés dans un sous-dossier tests

La configuration de pytest est gérée dans la section [tool:pytest] du fichier setup.cfg de chaque projet.

Outillage#

Il existe de nombreuses listes de packages recommandés, mais voici ma sélection personnelle. Je ne mets ici que les bibliothèques qui ne sont pas spécifiquement liées à la géomatique puisqu'il s'agit d'outillage, non du coeur de métier.

La base#

• black : formatage et homogénéisation du code automatisés, parce-que l'indentation à la main ou les débats de syntaxe, ça va 5 minutes
• flake8 : analyse statique de code (linter) qui permet de lever des incohérences ou des problèmes dans le code
• setuptools : packaging et installation de dépendances
• twine : publication sur PyPi
• wheel : packaging et installation de dépendances

Protagonistes#

• click : framework pour créer des outils en ligne de commande. A noter qu'il existe un surensemble très prometteur : Typer.
• django ou Flask pour les applications webs, même si je pense désormais utiliser FastAPI pour les prochaines APIs.
• requests : requêtes HTTP/S faciles, à la base du SDK . Cependant, évolue peu donc envisager d'autres options : httpx.

Seconds rôles#

• peewee : ORM SQL très léger et efficace (utilisé par Flask par exemple)
• pipenv : gestion du workflow de développement (environnements virtuels, dépendances…). Optionnel, sans besoin spécifique, se contenter de pip. Envisager aussi poetry
• PyInstaller : transforme les projets Python en exécutable (compatible avec la plateforme sur lequel il est utilisé)
• PyQt : bindings Python du framework d'interface graphique et tout le reste (réseau, threads, etc.)
• pytest : framework de tests.
• python-dotenv : lecture/écriture de fichiers de configuration au format .env
• requests-oauthlib : outillage pour gérer les différents scénarios oAuth2 (basé sur requests)
• sphinx : générateur de documentations rédigées en .rst (ou markdown) dans différents formats (PDF, epub, HTML). Utilisé pour générer les docs en ligne à partir du code, par exemple avec Read The Docs.

Figurants#

• docx-tpl : écriture de fichiers Word à l'aide de templates Jinja2
• LXML : outillage complet pour le XML et autres langages balisés (HTML...)
• OpenPyXl : lecture/écriture de fichiers Excel
• pre-commit : automatisation de certaines tâches liées à des étapes du processus git. Par exemple : lancer le formatage du code avec black au moment de git commit.

Auteur#

Julien Moura#

Géographe "sigiste" de formation, j'ai d'abord travaillé sur différentes thématiques et types de structures : la gestion des déchets en milieu urbain à Madagascar, le foncier d'intérêt général auprès de l'EPF de La Réunion, l'organisation et la résilience urbaine face aux risques naturels à Lima pour l'IRD.

C'est en m'intéressant à la gouvernance et à l'ouverture des données géographiques que je travaille à Isogeo quelques années. L'occasion d'asseoir mes compétences en développement et gestion de produit informatique. En 2020, je deviens indépendant (In Geo Veritas) puis rejoins les rangs d'Oslandia.

Féru des dynamiques de contributions, je participe activement à Geotribu depuis fin 2011 et, comme ça me manquait trop, j'ai décidé de lancer sa renaissance en 2020.