LinuxFr.org : les dépêches de Python

Profileur mémoire MALT 1.6.0 et support de Python

2026-01-30T14:55:36+01:00

MALT c'est quoi ?

L'optimisation est une activité connue de bien des développeurs, fouiller, chercher dans son code, pour, peut être, gagner un peu de performance (beaucoup, parfois). Dans cette tâche ardue, face à des codes grandissants, massifs, utilisant de nombreuses bibliothèques externes, un outil central dans ce travail de fourmi : le profileur.

Le profileur fait partie des outils importants pour le développeur qui se soucie des ressources qu'il utilise. Il lui permet de chercher les points chauds dans son code, comprendre le cout de chaque fonction, chaque ligne implémentée. Bien des outils s'intéressent à une chose : bien utiliser votre processeur.

Mais que se passe-t-il si vous rencontrez des difficultés avec l'utilisation de votre mémoire ? Si vous pensez mal utiliser la fonction malloc() du C ou l'opérateur new du C++ ? Si vous avez oublié qu'une de vos variables globales occupe 10 Go (surtout en Fortran) ?

Publié il y a quelques années MALT (licence CeCILL-C) permet de répondre à la question en cherchant toutes les allocations mémoires faites par votre code. Cet outil avait fait l'objet d'un article sur LinuxFR en 2018 lors de sa mise en open source : Profileurs mémoire MALT et NUMAPROF.

lien nᵒ 1 : Site officiel de MALT
lien nᵒ 2 : Dépôt github
lien nᵒ 3 : Premier article LinuxFR sur MALT

Versions 1.6.0

Avancées

Depuis, cet outil fait son chemin avec l'ajout du support de Rust ainsi que nombreuses corrections et ajouts tels que la possibilité de dumper le profile mémoire juste avant que le système ne soit plein.

malt -o dump:on-sys-full-at=80% -o watch-dog=true ./mon_programme

# également :
#  -o dump:on-app-using-rss=10G
#  -o dump:on-app-using-virt=80%
#  -o dump:on-app-using-req=500M

La possibilité de suivre les appels à mmap, mremap, munmap si vous les appelez directement dans votre code au lieu de laisser malloc faire son travail.

Support de python

MALT a initialement été développé dans le contexte du calcul à haute performance — HPC (High Performance Computing) donc surtout pour le C / C++ / Fortran / Rust.

Dans la communauté scientifique, nous voyons dans les laboratoires de plus en plus fleurir l'usage d'un langage à priori bien éloigné de nos prérogatives de performances : Python.

Dans un cadre de calcul scientifique, il est souvent utilisé plutôt comme un wrapper permettant d'appeler et d'orchestrer des bibliothèques en C /C++ / Fortran, elles, performantes. Quoi que l'usage amène aussi à l'écrire de certaines parties du code en Python grâce à Numpy ou Numba pour accéléré la partie calcule sur des tableaux ou autres frameworks d'exploitation des GPU.

La version 1.6.0 de MALT vient d'ajouter le support (encore quelque peu expérimental) natif de Python permettant d'analyser un code pur python ou mix Python / C / C++…. Il s'agit pour l'instant de la première version avec ce support, il reste donc du travail.

Sont supportés les versions Python supérieures à 3.11 ainsi que les environnements Conda / Anaconda / Venv. À l'heure de rédaction de cet article, cela comprend les versions 3.11 à 3.14.

MALT étant orienté C / C++, il ne supporte que Linux comme système d'exploitation. (NdM: la causalité évoquée ici devrait faire réagir des développeurs d'autres systèmes libres notamment :))

Utilisation sur Python

Si la commande malt fonctionne parfaitement, il est recommandé d'utiliser le wrapper malt-python qui adapte quelques configurations spécifiques à Python non encore automatiques.

malt-python ./script.py

# équivalent à 
malt --profile python-default ./script.py

# liste des profiles
malt --profile help

# Afficher le profile
malt-webview ./malt-script-py-6889.json

Profilage rapide

Notons que l'overhead de MALT est important en Python du fait du large nombre d'allocations générées par ce langage et de la méthode de résolution des piles d'appels pour retrouver les lignes dans votre code. Ces détails d'analyse peuvent être désactivés via :

# Désactivé complète de l'analyse des piles
malt-python -p python-no-stack ./my_script.py

# Analyse des piles par "sampling"
malt-python -p python-sampling ./my_script.py

Nouvelle interface

La version 1.6.0 arrive également avec une nouvelle interface graphique avec un code remis à jour
par rapport à sa version originale vieillissante.

Profil statique

Pour ceux qui voudraient échanger les profils avec d'autres sur d'autres OS, il est possible depuis la 1.6.0 de générer une version statique des pages de l'interface (hors annotation des sources et arbre d'appel navigable) via :

# Toues les pages possible en statique
malt-webview -static ./report malt-progr-123456.json

# Seulement la page de résumé.
malt-webview -static-summary ./report malt-progr-123456.json

Installation

MALT n'est pas encore disponible dans les distributions classiques, vous devez donc le compiler et l'installer à la main. Le nombre réduit de dépendances obligatoires en fait un outil relativement facile à installer.

On trouvera la procédure dans la documentation du projet.

Documentation

La documentation a été complètement ré-écrite et disponible sur le site officiel : documentation.

Outils similaires pour Python

Découvrir un outil est aussi l'occasion d'en découvrir d'autres. Restons dans le monde du Python, si MALT ne vous convient pas vous trouverez peut-être votre bonheur avec les outils suivants et complémentaires à MALT et eux totalement dédiés au Python toujours pour la mémoire :

Memray (Apache Public License 2)
Scalene (Apache Public License 2)

MALT se positionne par rapport aux deux présentés en apportant une analyse fine en annotant tout le source code de l'application. Il offre également une analyse des variables globales et TLS coté C/C++/Fortran/Rust.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

PyConFR 2025, planning et inscriptions

2025-09-24T08:57:44+02:00

La PyConFR 2025 a lieu du jeudi 30 octobre au dimanche 2 novembre au Campus René Cassin à Lyon. Le planning est en ligne et les inscriptions sont ouvertes !

Comme toujours, l’évènement est gratuit et l’inscription est obligatoire.

Les deux premiers jours de la conférence seront occupés par les sprints. Et les deux jours suivants seront dédiés aux conférences (longues et courtes) et ateliers.

Trois keynotes sont au programme :

Embracing Weird Code, d’Ivana Kellyer
Le rêve de tout enfant - devenir DBA ?, de Karen Jex
Être un·e allié·e du numérique pour tou·te·s en environnement hostile, de Morgane Rozenn Hauguel

lien nᵒ 1 : PyConFR 2025
lien nᵒ 2 : Programme de la PyConFR 2025
lien nᵒ 3 : Inscriptions
lien nᵒ 4 : Code de conduite
lien nᵒ 5 : Soutenir l’évènement
lien nᵒ 6 : Association Francophone Python

Un atelier de programmation pour les enfants (à partir d’environ 7 ans) a lieu le samedi après-midi.

Un espace enfants (de 3 ans à 12 ans) est aussi mis à disposition le samedi et dimanche gratuitement et sur inscription.

Un déjeuner PyLadies a également lieu durant la conférence. Un des objectifs est de tisser des liens entre la communauté PyLadies et le reste de la communauté Python francophone.

En plus du traditionnel repas du samedi soir, des visites guidées de Lyon sont aussi possibles les jeudi et vendredi soir, toujours sur inscription.

Enfin, le dimanche matin, l’AFPy tient son assemblée générale. Si vous souhaitez y voter, assurez-vous d’être à jour de cotisation.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Kivy : un cadriciel graphique unique en Python

2025-05-06T17:13:18+02:00

Kivy est un cadriciel (framework) graphique, permettant de développer des interfaces tactiles (ou utilisable à la souris) sur toutes les plateformes, y compris mobiles. Il s'accompagne d'une suite de logiciels très pratiques que nous allons présenter ici.

lien nᵒ 1 : site officiel
lien nᵒ 2 : Kivy Garden (extensions)
lien nᵒ 3 : KivyMD
lien nᵒ 4 : Un très bon point d'entrée en français (merci chyek)

Sommaire

Kivy : boîte à outils graphique multi-plateformes
kv : interface graphique en déclaratif
- Les propriétés
Plyer : accéder facilement aux fonctionnalités matérielles de votre appareil
Python For Android : utiliser Python… sur Android
Kivy for iOS : déployez sur les appareils Apple
Pyjnius : utiliser l’API Java Android depuis Python
KivyMD, des widgets Material Design
Quelques limitations
Conclusion
Une note d’histoire

Kivy : boîte à outils graphique multi-plateformes

Kivy permet de créer des interfaces graphiques naturellement adaptées aux écrans tactiles (mais qui restent utilisables sur un environnement de bureau traditionnel, à la souris et sans écran tactile). Il est écrit principalement en Python mais les parties critiques sont écrites en Cython, ce qui lui permet d’avoir de bonnes performances.

Une interface Kivy peut s’écrire de deux façons (ou, plus couramment, par une combinaison de ces deux façons) : en Python directement, ou via kv, une syntaxe déclarative dont nous parlons plus bas.

Pour vous donner une idée, voici un exemple de hello world repris du site officiel de Kivy :

from kivy.app import App
from kivy.uix.button import Button

class TestApp(App):
    def build(self):
        return Button(text='Hello World')

TestApp().run()

Ce qui donnera :

Une interface est composée de « widgets » agencés via des « layouts ». Certains widgets permettent de facilement mettre en place des composants communs de nos jours, comme par exemple le widget Carousel :

D’autre part, Kivy fournit des outils qui simplifient la vie du développeur ou de la développeuse, en particulier un système de propriétés (à ne pas confondre avec les propriétés Python) qui permet de mettre automatiquement l’interface à jour quand elles sont modifiées, ou de facilement attacher une fonction de rappel (« callback »), voir plus bas pour un exemple simple. On peut aussi citer un mécanisme d’animations très pratique et efficace.

kv : interface graphique en déclaratif

kv est un langage permettant de décrire des interfaces, il met à profit les propriétés mentionnées plus haut et l’interface va se mettre à jour automatiquement quand des propriétés utilisées dans kv sont modifiées.

Reprenons le hello world vu plus haut, et faisons-le avec kv:

Widget:
    Button:
        text: "Hello World"

Plutôt simple non ?
Le code kv est généralement mis dans des fichiers séparés avec l’extension .kv.

Les propriétés

Kivy a donc un concept de propriété, qui permettent la liaison de données bidirectionnelles (two-way data binding), ou en d’autres termes de facilement avoir l’état mis à jour entre le code python et l’interface décrite dans le fichier kv. C’est à l’usage très pratique et facile.

Un exemple va sans doute aider à comprendre.

Commençons par faire un environnement virtuel Python avec Kivy:

$ mkdir demo

$ cd demo

$ python -m venv env

$ source env/bin/activate

$ pip install kivy

Ensuite créez le fichier demo.py suivant :

from kivy.app import App
from kivy.uix.boxlayout import BoxLayout
from kivy.properties import NumericProperty

class CompteurWidget(BoxLayout):
    compteur = NumericProperty(0)

    def increment(self):
        self.compteur += 1

class DemoApp(App):
    def build(self):
        return CompteurWidget()

DemoApp().run()

Et maintenant, dans le même répertoire, ajoutez le fichier demo.kv suivant, ce dernier sera automatiquement découvert par Kivy parce qu’il s’appelle comme notre application (DemoApp) sans le suffixe App et en minuscule :


<CompteurWidget>:
    orientation: 'vertical'
    padding: 20

    Label:
        text: str(root.compteur)
        font_size: 30

    Button:
        text: "Incrémenter"
        on_press: root.increment()

Il ne nous reste plus qu’à lancer le programme :

python demo.py

Et à admirer :

Le label se met automatiquement à jour quand le compteur compteur est incrémenté.

La lectrice ou le lecteur assidu de DLFP pourra faire un TapTempo en exercice.

Note: Ne vous arrêtez pas au fait que l’UI est un peu "moche" par défaut, il y a des extensions beaucoup plus attractives (cf. KivyMD plus bas), et il est très facile de personnaliser l’interface et d’en faire une très belle en modifiant un peu ses fichiers .kv.

Plyer : accéder facilement aux fonctionnalités matérielles de votre appareil

Plyer est une bibliothèque permettant d’accéder à nombre de fonctions utiles de manière indépendante de la plateforme. Ainsi vous avez une API commune pour afficher une notification, demander l’état de la batterie, faire vibrer l’appareil, faire de la synthèse vocale de texte (« text-to-speech »), ouvrir un fichier avec le dialogue natif de la plateforme, etc.

Bien que développé par la même équipe que Kivy, ce paquet est utilisable indépendamment et est donc particulièrement utile pour n’importe quel projet multi-plateformes. Référez-vous à la page du projet pour avoir un tableau des fonctionnalités supportées selon les plateformes, et à la documentation pour plus de détails.

Python For Android : utiliser Python… sur Android

Si vous souhaitez distribuer votre application sur Android, vous allez devoir avoir une version de Python compilée pour cette plateforme, ainsi que de tous les paquets nécessitant une compilation.

C’est le rôle de Python pour Android, qui est une collection d’outils qui s’appuient sur l’Android SDK pour permettre d’utiliser Kivy ou d’autre paquets Python sur Android, et ainsi faire votre propre distribution Python.

Si vous utilisez un paquet qui n’est pas en pur Python (c’est-à-dire qu’il y a des parties à compiler) et qui n’est pas encore disponible ou qui l’est mais dans une version trop ancienne, vous pouvez écrire ou mettre à jour des « recettes » (recipes en anglais) qui indiquent comment compiler. Référez-vous à la documentation pour voir comment faire.

Notez toutefois qu’il y a une pénalité à utiliser du Python par rapport à une application dans un langage compilé : il faut charger l’interprète au démarrage, et au tout premier lancement de votre application (et uniquement au premier) il y a aura une phase de décompression de vos fichiers. En dehors de ces petits inconvénients, ça fonctionne très bien.

Là encore, le projet est indépendant de Kivy et peut être utilisé avec un autre cadriciel.

Kivy for iOS : déployez sur les appareils Apple

À l’instar d’Android, l’équipe de Kivy fournit les outils pour faire votre distribution Python pour iOS.

Il vous faudra posséder une machine Apple pour les utiliser, à cause des restrictions imposées par cette plateforme (ceci n’est pas spécifique à Kivy pour iOS, mais s’applique à tous les outils pour développer sur iOS).

Ainsi avec une seule base de code (et après avoir passé un peu de temps pour configurer correctement les outils de compilation), vous pouvez déployer votre application Kivy/Python sur toutes les plateformes majeures (hormis le web, pour lequel il existe d’autres options comme Brython, Pyodide ou PyScript, mais c’est un sujet pour une autre dépêche).

Pyjnius : utiliser l’API Java Android depuis Python

Parfois l’utilisation de Plyer mentionné plus haut et de la bibliothèque standard Python ne suffisent pas, et vous avez besoin d’accéder à l’API d’Android, mais cette dernière est faite pour être utilisée avec Java ou Kotlin.

Pour pouvoir utiliser l’API d’Android depuis Python, PyJNIus est disponible. Ce paquet permet d’accéder aux classes Java comme à des classes Python en utilisant JNI (« Java Native Interface » ou « Interface Native de Java »).

Ce paquet fournit une méthode autoclass qui convertit automatiquement une classe Java en Python, c’est très facile à utiliser et souvent suffisant pour les cas simples.

KivyMD, des widgets Material Design

KivyMD n’est pas un projet officiel de l’équipe Kivy, mais un projet tiers dédié à la création d’un ensemble de Widgets thémables adoptant Material Design.

L'image ci-dessus est issue de la documentation de KivyMD, vous trouverez également des démos vidéo sur le dépôt du projet.

Quelques limitations

Une petite note sur mon expérience personnelle (Goffi). Kivy est un excellent cadriciel, et l’équipe est accueillante et réactive : c’est un projet que je recommanderais en général. Ceci dit, dans mon cas particulier (un client XMPP ayant de nombreuses fonctionnalités), j’ai quelques limitations qui me poussent actuellement à chercher des alternatives, notamment basées sur Qt (PyQt et PySide) :

l’accessibilité est un problème majeur. L’équipe y travaille, mais aujourd’hui les applications Kivy ne sont pas accessibles. C’est notamment dû au fait que l’interface utilisateur est entièrement gérée par Kivy, au lieu d’utiliser des composants natifs, et c’est un point complètement bloquant pour moi.
il n’y a pas de webview ou de rendu HTML natif, ce qui est bloquant parce que je fais du rendu de blogs.
le rendu de texte est incomplet, notamment sur les plateformes mobiles. C’est compliqué de faire un rendu riche avec des émojis, par exemple, un gros problème pour une application de messagerie de nos jours.
le support des portails Freedesktop est inexistant : il faut faire l’implémentation à la main, alors qu’il est natif sur des cadriciels majeurs comme GTK ou Qt. Je pense par exemple à l’ouverture ou l’enregistrement de fichier. Les portails sont particulièrement nécessaires si on veut voir son application sur Flatpak. Plus de détails sur ce ticket.
le support Wayland existe, mais lors de mes tests sur des distributions GNU/Linux sur Pinephone, il n’a pas fonctionné et je n’ai pas pu afficher l’application.
le chargement de l’interprète Python prend un certain temps, ce qui rend le lancement de l’application sur plateformes mobiles telle qu’Android et probablement iOS (que je n’ai pas testé) un peu lent. Sachant que sur ces plateformes l’application peut être tuée à n’importe quel moment auquel cas il faut tout relancer, cela peut mener à une mauvaise expérience utilisateur. Ceci dit, avec une distribution optimisée (en enlevant les paquets non utilisés), et sur les téléphones actuels qui sont très puissants, le problème est sans doute moindre.

Notez que je n’ai pas eu l’occasion de travailler avec Kivy récemment, peut-être que ces remarques ne sont plus à jour. Merci d’indiquer en commentaires s’il y a eu de l’évolution sur ces points.

Aussi, mon cas d’utilisation est très demandant (rendu HTML, affichage de texte performant, etc). Dans la plupart des cas, Kivy remplit sans problème toutes les cases (sauf l’accessibilité, qui reste son problème le plus important à mon sens).

Conclusion

Comme vous pouvez le voir, un travail considérable a été effectué sur Kivy et son écosystème, et il en sort un cadriciel performant, pratique, et qui peut potentiellement fonctionner sur la plupart des plateformes. Kivy est agréable à utiliser, et dispose d’une communauté très active et disponible.

Ce cadriciel mérite de s’y attarder, et est une option sérieuse si vous voulez développer un projet rapidement pour une ou plusieurs plateformes.

Une note d’histoire

Cette dépêche a été commencée le 04 octobre 2018 à 14:19 (au premier jour de la Pycon FR 2018, à Lille, où une partie de l’équipe de Kivy était présente). Je crois que c’est haut la main la dépêche qui est restée le plus longtemps dans l’espace de rédaction. Comme quoi, tout vient à point à qui sait attendre, comme dirait l’autre.

Merci à toutes les personnes qui ont participé à la correction de la dépêche.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

PyConFR 2025, à Lyon du 30 octobre au 2 novembre

2025-05-05T11:42:51+02:00

L’Association Francophone Python (AFPy) organise la PyConFR 2025 du jeudi 30 octobre au dimanche 2 novembre. Pour cette 16e édition, nous sommes accueillis par le Campus René Cassin de Lyon !

lien nᵒ 1 : PyConFR 2025
lien nᵒ 2 : Proposer un sujet à la PyConFR 2025
lien nᵒ 3 : Supporter l’évènement
lien nᵒ 4 : Association Francophone Python (AFPy)
lien nᵒ 5 : Code de conduite de la PyConFR

La PyConFR, c’est un évènement gratuit sur 4 jours autour du langage de programmation Python. Elle est composée deux jours de développements participatifs (sprints), puis de deux jours de conférences et ateliers.

L’appel à propositions est ouvert jusqu’au 20 juillet. Peu importe votre niveau en Python, vous pouvez proposer un sujet de sprint, de conférence ou d’atelier ! Venez parler de développement logiciel, de diversité, de communauté, faire un retour d’expérience sur un outil, présenter votre projet, un domaine d’activité…

Comme tous les ans, nous proposons aux personnes habituellement peu représentées en conférence de l’aide pour trouver un sujet, rédiger la proposition de conférence, rédiger le support de conférence et pour répéter. Vous pouvez nous contacter à l’adresse [email protected]">[email protected] si vous pensez en avoir besoin.

Enfin, la PyConFR est entièrement financée par les sponsors. Si vous connaissez des sponsors potentiels, n’hésitez pas à leur parler de l’évènement !

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

PyConFR 2024, planning et inscriptions

2024-09-19T18:03:56+02:00

La PyConFR 2024 a lieu du jeudi 31 octobre au dimanche 3 novembre à l’UFR Mathématique et d’Informatique de Strasbourg. Le planning est disponible et les inscriptions sont ouvertes !

Comme toujours, la PyConFR est un évènement gratuit et l’inscription est obligatoire.

Les deux premiers jours de la conférence seront occupés par les sprints. Et les deux jours suivants seront dédiés aux conférences (longues et courtes) et ateliers.

Trois keynotes sont également au programme :

De villageoise à l’itWoman… Quelles actions pour faire de mon rêve TECH une réalité ?, par Houleymatou Baldé
Recherche des bonnes pratiques de packaging, par Françoise Conil
Reality is not an end-to-end prediction problem: Applied NLP in the age of Generative AI, par Ines Montani

Cette année, un espace enfants (de 3 ans à 12 ans) est mis à disposition gratuitement sur inscription. Vous pouvez inscrire vos enfants jusqu’au 15 octobre.

Durant cette édition, c’est aussi le retour du déjeuner PyLadies. Un des objectifs est de tisser des liens entre la communauté PyLadies et le reste de la communauté Python francophone.
Les inscriptions au déjeuner PyLadies sont ouvertes jusqu’au 27 octobre.

Le dimanche matin, l'AFP y tiendra son assemblée générale. Si vous souhaitez y voter, assurez vous d'être à jour de cotisation.

lien nᵒ 1 : PyConFR 2024
lien nᵒ 2 : Programme de l’évènement
lien nᵒ 3 : Inscriptions
lien nᵒ 4 : Code de conduite de la PyConFR
lien nᵒ 5 : Association Francophone Python (AFPy)
lien nᵒ 6 : Supporter l’évènement

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Mise à jour de VenC en version 3.2.2

2024-06-09T10:18:30+02:00

VenC, un générateur libre (GPLv3) de site statique en python qui avait déjà été présenté dans une dépêche précédente, est de retour en version 3.2.2 avec tout un tas de nouvelles fonctionnalités cool qu’on va voir ici.

lien nᵒ 1 : Site de l'auteur
lien nᵒ 2 : Site de Jérémy Berry
lien nᵒ 3 : Site du projet
lien nᵒ 4 : Tipeee
lien nᵒ 5 : Liberapay

Sommaire

Auto-rafraîchissement lors de la prévisualisation
Assignation d’un thème par défaut
Amélioration des fonctionnalités FTP
Thème par défaut
Nouvelles balises VenC
Le mot de la fin

Auto-rafraîchissement lors de la prévisualisation

Quand vous prévisualisez votre site avec venc -s vous n’avez plus besoin de tuer le processus du serveur HTTP local et de régénérer manuellement le site à chaque modification. Le mécanisme est à présent automatique et détecte lui-même un changement pour vous présenter la version à jour de votre contenu ! La cache du navigateur étant parfois capricieux, VenC vous notifie dans la sortie standard de ses actions si jamais vous avez un doute.

Assignation d’un thème par défaut

Si vous utilisez le thème par défaut concrete ou tout autre thème installé en dehors de votre projet il est possible de l’indiquer dans votre fichier de configuration. Ainsi venc -s sait comment régénérer votre site si nécessaire, et vous n’avez plus besoin d’indiquer le nom du thème installé sur votre système lorsque vous utilisez la commande venc -xb ou venc -xftp.

Amélioration des fonctionnalités FTP

De nombreuses améliorations ont été apportées, en voici quelques-unes !

Transfert parallèle

Vous pouvez maintenant définir un nombre arbitraire de connexions FTP simultanées pour le transfert de votre site en ligne. Pour un petit site, ça ne fait pas de grosse différence, mais quand comme moi votre site comporte plusieurs centaines de pages, ça fait gagner un temps fou !

Verbosité accrue

Affichage du prompt FTP
Affichage des commandes FTP associées à leur numéro de session

Transfert intelligent

Pour économiser de la bande passante, VenC compare les fichiers locaux avec ceux en ligne. Ce faisant, il ne réalise que les opérations d’I/O strictement nécessaires.

Configuration FTP plus fine

Vous pouvez maintenant paramétrer les options suivantes :

ftp_encoding : VenC affichant à présent le prompt FTP du serveur, il est maintenant possible d’avoir des informations sur celui-ci, et notamment l’encodage. Avec l’option ftp_encoding, il est donc possible de configurer l’encodage de la session pour être en phase avec le serveur distant et éviter de mauvaises surprises.
ftp_sessions : comme on l’a vu plus haut, c’est le nombre de connexions parallèles possibles.
ftp_port : avant, pour une raison obscure et injustifiable par le bon sens, le port de la connexion FTP était codé en dur… Maintenant c’est une valeur par défaut qu’il est possible de redéfinir.

Thème par défaut

Le thème par défaut a été amélioré, notamment au niveau de l’ergonomie et de la qualité visuelle du thème. Ce nouveau thème intègre par ailleurs les nouvelles fonctionnalités de la version 3.2 !

Nouvelles balises VenC

Accès amélioré à des métadonnées YAML

Une fonctionnalité ultérieurement manquante et utile dans certains cas d’usage est de pouvoir accéder à des valeurs qui sont imbriquées dans un ou plusieurs dictionnaires YAML dans le fichier de configuration principal ou dans les métadonnées d’une publication.

Pour ce faire, quatre fonctions VenC ont été ajoutés :

Pour les champs non obligatoires ou non prédéfinis par VenC, ça permet donc en conséquence une plus grande liberté dans l’organisation du contenu YAML.

Accéder à la date de la dernière publication

Utile pour la génération de flux Atom ou RSS, récupérer la date de la dernière publication d’un fil de publication permet d’indiquer la vraie date de mise à jour du flux :

GetLastEntryTimestamp

Taxonomie Avancée

C’est la grosse fonctionnalité de cette mise à jour !

Avant la version 3.2 vous ne pouviez organiser vos publications “que” par catégories hiérarchisées. C’était déjà pas mal dans la mesure où ça permettait de créer des menus arborescents pour organiser votre contenu, mais parfois ça n’est pas suffisant. Par exemple, tout à fait au hasard, vous êtes un⋅e artiste et vous gérez votre portfolio avec VenC. Vous pourriez alors avoir un menu de la forme suivante pour organiser vos œuvres :

- Peintures
  - Huile
  - Acrylique
  - Aquarelle
- Dessins
  - Encre
  - Crayon
- Mediums Mixtes

Et comme vous êtes un⋅e bon⋅ne p'tit⋅e libriste auto-radicalisé⋅e sur Framasoft et LinuxFr vos œuvres sont en partie sous licence CC-By-SA. En partie seulement car oui, vous faites aussi des fanarts, des travaux dérivés d’œuvres sous licences propriétaires. Vous voulez donc séparer ce qui est véritablement libre de ce qui ne l’est pas. En générant par exemple ce type de menu :

# Mediums

- Peintures
  - Huile
  - Acrylique
  - Aquarelle
- Dessins
  - Encre
  - Crayon
- Mixtes

# Licences

- CC
  - By-NC-ND
  - By-SA
- Copyright
- Licence Art Libre

Ça tombe bien, c’est précisément ce que permet maintenant de faire VenC 3.2.

L’idée est la suivante : puisque l’arbre de toutes les catégories construit à partir de toutes les publications est un arbre hiérarchisé, il suffit de sélectionner une ou plusieurs branches de cet arbre pour créer nos menus et présenter notre contenu de la façon qu’il nous plaira.

Dans notre exemple précédent l’arbre hierarchisé de toutes les catégories aurait donc la forme suivante :

- Mediums:
  - Peintures:
    - Huile
    - Acrylique
    - Aquarelle
  - Dessins:
    - Encre
    - Crayon
  - Mixtes
- Licences:
  - CC:
    - By-NC-ND
    - By-SA
  - Copyright
  - Licence Art Libre

Nous sélectionnons donc les branches Mediums et Licences. Avec les nouvelles fonctions VenC qui vont bien :

Sur le thème par défaut concrete, vous pouvez ainsi avoir un nombre arbitraire de menu de catégories en configurant comme indiqué dans la documentation votre fichier de configuration principal.

À noter que même si ça n’est pas encore idéal, ce système ouvre la voie pour créer des blogs multilingues. Le brainstorming sur le sujet se passe ici. Pour l’heure, il est donc possible de tirer avantage de la taxonomie avancée pour créer des branches pour chaque langue que vous souhaitez utiliser. Avec un peu de JS vous pouvez aller plus loin pour rendre ça plus dynamique à votre convenance.

Le mot de la fin

Voilà pour cette nouvelle version !

La version 3.3 est déjà en cours de développement et vous pouvez suivre l’aventure ici. Un grand merci à Sidoine, Rollniak et Jérémy pour leur aide, leur confiance et leurs feedbacks !

Les sources GIMP des illustrations sont accessibles ici sous licences CC-By-SA

Toutes les contributions sont évidemment les bienvenues :

Corriger, relire ou améliorer la documentation.
Signaler des bugs ou faire des suggestions.
Écrire du code.
Me faire aumône pour me payer un p'tit shot de Baileys Irish Cream !

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

PyConFR 2024, du 31 octobre au 3 novembre à Strasbourg

2024-05-13T17:03:16+02:00

L’Association Francophone Python (AFPy) organise la PyConFR 2024 du jeudi 31 octobre au dimanche 3 novembre. Pour cette 15^e édition, nous sommes accueillis par l’UFR Mathématique et d’Informatique de Strasbourg (https://mathinfo.unistra.fr/) !

Si vous ne connaissez pas la PyConFR, c’est un évènement gratuit sur 4 jours autour du langage de programmation Python. Tout d’abord, il y a deux jours de développements participatifs (sprints), puis deux jours de conférences et ateliers.

Vous pouvez proposer un sujet de sprint, de conférence ou d’atelier jusqu’au 21 juillet. Peu importe votre niveau en Python, n’hésitez pas à proposer un sujet ! Venez parler de développement logiciel, de diversité, de communauté, faire un retour d’expérience sur un outil, présenter votre projet, un domaine d’activité…

Dans un secteur aussi masculin que le développement informatique, nous proposons aux personnes habituellement peu représentées en conférence de l’aide pour trouver un sujet, rédiger la proposition de conférence, rédiger le support de conférence et pour répéter. Vous pouvez nous contacter à l’adresse [email protected]">[email protected] si vous pensez en avoir besoin.

Enfin, la PyConFR est entièrement financée par les sponsors. Si vous connaissez des sponsors potentiels, n’hésitez pas à leur parler de l’évènement !

lien nᵒ 1 : PyConFR 2024
lien nᵒ 2 : Association Francophone Python (AFPy)
lien nᵒ 3 : Proposer un sujet à la PyConFR 2024
lien nᵒ 4 : Code de conduite de la PyConFR
lien nᵒ 5 : Supporter l’évènement

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

VenC 3.1.1 | Un nouveau générateur de site statique

2024-02-01T10:21:43+01:00

On va présenter ici un nouveau générateur de site statique, écrit en python. Il n’est pas exactement nouveau au sens où nous en sommes à la version 3, mais jusqu’ici le projet est resté relativement confidentiel. Nous parlerons également des perspectives d’évolution de ce projet.

lien nᵒ 1 : Site et documentation du projet VenC
lien nᵒ 2 : Code source de VenC sur Github
lien nᵒ 3 : Code source de VenC sur Framagit
lien nᵒ 4 : Mistletoe
lien nᵒ 5 : Docutils
lien nᵒ 6 : Latex2MathML
lien nᵒ 7 : Pygments
lien nᵒ 8 : AsciiDoc3
lien nᵒ 9 : Site de l'auteur

Sommaire

Introduction et petit historique
Que permet de faire VenC ?
Faster, smaller, stronger
Travaux et réflexion en cours, le futur de l’application
Le mot de la fin
Ressources du projet
- Illustrations
- Modules optionnels

Introduction et petit historique

VenC est un ~~énième~~ générateur de site statique (libre, évidemment !) dont le nom étrange provient d’un rêve dans lequel je naviguais sur un réseau social appelé « V en C ». Ce rêve, ainsi que la forme et le contenu de ce réseau, m’avaient marqué. Rétrospectivement, ça ressemblait un peu aux premières heures glorieuses de Tumblr / Skyblog avec un petit côté web oldschool.

De gros projets historiques sont déjà bien installés dans le game. Par ailleurs, si j’en crois le nombre d’annonces de logiciels de ce type ici, ça ressemble un peu à un running gag d’arriver avec ma proposition !

Je tenais quand même à présenter l’ouvrage, car il s’agit d’un projet qui me tient toujours beaucoup à cœur et avec lequel j’ai notamment appris le langage Python et pour lequel je continue de progresser. Je l’ai commencé au début des années 2010 précisément quand on voyait émerger ce type d’outil, pour une approche plus “lightweight” du web. Ça n’est que récemment que j’ai ambitionné de rendre ce projet public.

La version 2 est la première que j’ai partagée sur mes réseaux sociaux (Diaspora* et Mastodon). C’était un peu la bêta de la version actuelle, où de grandes restructurations de code avaient été réalisées, fort d’une plus grande expérience en Python. Ça ne m’a pas empêché d’introduire de la dette technique corrigée plus tard, et dans sa plus grande partie je l’espère, dans la version actuelle. J’avais également ajouté une fonctionnalité un peu expérimentale, dont on reparlera plus bas.

Globalement la v1 et la v2 sont restées assez confidentielles. Trop de bugs, pas correctement documentées et pas assez adaptées aux multiples et imprévisibles usages que peuvent avoir les utilisateurs finaux. Certaines questions de choix technico-philosophiques restées en suspens sont encore d’actualité et doivent être décidées par ceux qui l’utilisent. En d’autres termes, je souhaite élargir les possibilités qu’offre VenC en l’adaptant aux besoins des autres, et non plus seulement aux miens.

La version 3.1.0 a été mise en ligne le 30 décembre 2023 et j’estime le projet suffisamment mature (en toute modestie) pour être partagé avec vous. Mon idée étant de proposer l’existant, et de réfléchir avec vous avec les perspectives que j’ai en tête ou que vous pourriez vouloir voir implémentées ! C’est également l’occasion pour moi de bénéficier d’un éventuel retour d’expérience, d’une relecture de code ou de la documentation, et améliorer l’existant.

Que permet de faire VenC ?

Il s’agit donc d’un générateur de site statique orienté blog proposant les fonctionnalités suivantes :

Des balises VenC permettant une mise en page et une intégration de contenus avancés.
La possibilité de créer un agencement de publication en nombre arbitraire de colonnes.
Un module et une API JavaScript de défilement infini.
Les publications peuvent être organisées par catégories, sous-catégories, par période de dates et par chapitres.
La possibilité de désactiver des fils de publications spécifiques.
La possibilité de configurer des sous-répertoires pour chaque type de publications.
La possibilité d’ajouter des métadonnées au blog et aux publications.
Les publications sont triées par ordre chronologique par défaut, mais peuvent l’être aussi en fonction de métadonnées. L’ordre peut être ascendant ou descendant.
La génération de flux Atom et/ou RSS pour chaque fils de publications.
Des permaliens.
Un serveur HTTP simple pour effectuer des tests et prévisualiser le site.
La gestion et l’édition du blog peuvent être faites entièrement en ligne de commande, dans un environnement non graphique.
Le support de Markdown, reStructuredText, AsciiDoc.
La mise en ligne du site peut se faire en FTP via VenC.
Le support de pygmentize pour la coloration syntaxique.
Le support de l’API oEmbed.
Le support de l’API Kroki.
Le support de contenus audio et vidéo via les balises VenC.
Installation facilitée via pip et pipx.

Faster, smaller, stronger

À noter qu’ayant à cœur l’optimisation et la performance, l’essentiel du travail réalisé sur cette version 3.1.0 à été l’intégration d’un mode de génération parallèle pour accélérer l’exportation de votre projet. En fait sur ce dernier point, l’ambition est de faire en sorte que VenC puisse passer à l’échelle en tirant parti ~~des threads Python~~ du module multiprocessing de Python. Nous en reparlerons plus bas.

J’ai passé de longues heures à optimiser l’ensemble du code comme je l’avais déjà fait entre la v1 et la v2. Mon propre site contenant énormément de pages, j’ai besoin d’une application rapide et simple pour générer celui-ci. Il y a quelque chose de très satisfaisant à travailler en ce sens. Tout en mesurant les limites de la chose et en découvrant qu’un excès de zèle rend le code incompréhensible bien sûr… Avec cette v3 je pense avoir atteint un équilibre. En termes de rapidité, la force de VenC réside aussi dans le fait qu’il possède sa propre syntaxe de balisage pour la mise en forme (pas de Jinja donc). Le moteur de template étant ici taillé sur mesure et fortement couplé à l’application, ça tourne très très vite ! Voir la documentation de la syntaxe VenC.

Si jamais ça vous intéresse, il est envisageable de découpler cette partie spécifique du code pour être utilisé ailleurs que dans VenC.

Travaux et réflexion en cours, le futur de l’application

Le moteur de recherche client-side.

Dans la v2 j’avais introduit une fonctionnalité expérimentale permettant de générer des documents JSON-LD au format JSON ou JSONP. Cette fonctionnalité a été retirée depuis, parce que je ne suis plus sûr de la pertinence de cette technique pour le projet initial : celui d’implémenter un moteur de recherche client-side décentralisé. Ce moteur de recherche devait permettre de chercher du contenu sur un site, mais aussi sur celui des amis, pour lesquels les end-points seraient manuellement ajoutés par le propriétaire du site. Ce faisant, cela permettrait de créer un réseau de site qu’il est possible de crawler pour trouver du contenu.

Il se pourrait que JSON-LD ne soit en fait pas le meilleur moyen pour ce genre d’usage. Mais je n’en sais trop rien, qu’en pensez-vous ?

Intégration avec le Fediverse

Un truc que j’ai toujours trouvé chouette avec Tumblr, c’est le fait d’avoir une page hautement personnalisable qui fait néanmoins partie d’un tout qu’il est possible d’explorer avec le moteur de recherche interne du service. En ce sens, cette idée rejoint celle concernant le moteur de recherche client-side décentralisé.

Avec l’émergence de Fediverse, ça serait en fait intéressant de voir comment il est possible d’intégrer VenC à ce type de réseau. Mon idée initiale était de créer une surcouche de VenC, une sorte de serveur, avec un frontend web, gérant plusieurs sites et capable de répondre dynamiquement à des requêtes des APIs du Fediverse. On comprend ici qu’un tel serveur pourrait avoir à gérer des dizaines, voire des centaines de sites, le parallélisme fraîchement implémenté dans la v3 prend tout son sens.

La question de comment explorer du contenu gérer par VenC de façon décentralisé, modulaire, et interopérable étant le grand axe d’évolution de VenC qui me tient à cœur. Je souhaite recréer ce réseau dont j’avais rêvé il y a longtemps.

Sites statiques, deepweb et smolweb

Le smolweb, c’est vraiment cool. Par certains aspects il ressemble aussi un peu au deepweb, lui aussi très intéressant pour d’autres raisons. Les propositions de ces réseaux étant toujours plus d’actualités à mesure que les années passent…

De ce que j’ai pu voir du deepweb, beaucoup de sites sont en fait statiques et d’apparence très sobre, ce qui ne manquera pas de faire vibrer la fibre nostalgique de ceux qui ont connu le web des années 1990 et 2000. Quelle époque ! Dans les deux types de réseau on retrouve deux aspects qui me tiennent à cœur, le green IT pour l’un et la vie privée pour l’autre. Des valeurs dans lesquelles je me retrouve évidemment, et pour lesquelles je souhaiterais que VenC apporte sa pierre à l’édifice.

Une des perspectives d’évolution de VenC serait de pouvoir faire en sorte qu’il puisse générer des sites spécifiquement pour les différents types de smolweb : Gopher, Gemini… Mais je ne connais pas bien le fonctionnement de ceux-là, c’est donc encore à l’étude.

Et le format EPUB ?

Puisque VenC gère le chapitrage de son contenu, ça pourrait avoir du sens de pouvoir générer des documents EPUB. Et comme ce format est en fait du contenu HTML embarqué dans un zip… Il n’y a plus qu’à étudier les spécifications du format, et au boulot. Mais peut-être qu’il existe déjà un module ou package Python pour ce genre de chose ? Tout ça est aussi à l’étude.

Internationalisation des articles

Le besoin étant d’avoir plusieurs versions d’un même article dans des langues différentes, il y a plusieurs façons de réaliser ça… Ça n’est donc pas une feature triviale.

Ça pourrait m’aider de me parler un peu de la façon dont vous voyez la chose pour un blog statique.

Fonctionnalités de base manquantes

La plupart des générateurs de sites statiques ont cette fonctionnalité, mais pas VenC. Pas encore en tout cas, mais c’est dans les tuyaux !

Génération incrémentale et mise en cache.

Au lieu de régénérer tout le site à chaque modification, VenC ne devrait modifier que le strict nécessaire. Une mise en cache des pages à certaines étapes de la génération du site pourrait être mise en œuvre pour accélérer le traitement.

Auto-rafraîchissement lors de la prévisualisation

Cette fonctionnalité va de pair avec la précédente, lorsque le site est prévisualisé il devrait s’auto-régénérer quand une modification est faite.

Ajout de modules tiers écrit par les utilisateurs eux-mêmes

Pour le moment VenC n’a pas de greffons autres que ceux déjà prévus par l’application, mais les futures versions bénéficieront d’une API permettant d’écrire vos propres fonctionnalités.

Le mot de la fin

J’ai à cœur de rendre ce logiciel accessible dans d’autres langues, pour la traduction de la documentation et du logiciel lui-même, je cherche des personnes pouvant justifier d’une capacité professionnelle de traduction dans une langue ou une ou autre. L’anglais et l’allemand seraient par exemple un bon début. Ce travail serait naturellement rémunéré. N’hésitez pas à me contacter si vous pensez avoir la compétence requise pour que nous en discutions.

Cette v3 a demandé beaucoup d’efforts, j’espère que ce logiciel trouvera ses utilisateurs ! J’en profite pour remercier les contributeurs qui croient en ce projet et notamment Jérémy Berry pour ses conseils et sa précieuse relecture, Sidoine Baratte qui suit le projet depuis le début et avec qui j’ai affronté les bugs ainsi que benben962 pour sa traduction en anglais de l’ancienne documentation !

Ressources du projet

Illustrations

Les sources des illustrations :

Modules optionnels

Mistletoe : Pour l’utilisation de la syntaxe Markdown.
Docutils : Pour utiliser la syntax reStructuredText.
Latex2MathML : Pour convertir du LaTeX en MathML.
Pygments : Pour la coloration syntaxique.
AsciiDoc3 : Pour utiliser la syntaxe Asciidoc

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

L'installation et la distribution de paquets Python (2/4)

2023-12-21T10:09:58+01:00

Cette dépêche est la deuxième d’une série de quatre sur le packaging en Python :

L’histoire du packaging Python
Tour de l’écosystème actuel
Le casse-tête du code compilé
La structure de la communauté en question

Je vais donc proposer un aperçu plus ou moins complet des différents outils, et de ce qu’ils font ou ne font pas, en essayant de les comparer. Mais je parlerai aussi des fichiers de configuration, des dépôts où les paquets sont publiés, des manières d’installer Python lui-même, et de l’interaction de tout ceci avec les distributions Linux. En revanche, je laisse de côté pour l’instant les paquets écrits en C, C++ ou Rust et la complexité qu’ils apportent.

lien nᵒ 1 : Guide officiel du packaging Python
lien nᵒ 2 : Liste de projets (sur ce même guide)

Sommaire

Commençons par un outil dont à peu près tout utilisateur de Python a entendu parler : pip.

Pip

L’installeur de paquets pip est un outil fondamental et omniprésent. Son nom est un acronyme récursif signifiant « Pip Installs Packages ». Il permet d’installer un paquet depuis le PyPI, mais aussi depuis une copie locale du code source, ou encore depuis un dépôt Git. Il dispose, bien sûr, d’un résolveur de dépendances pour trouver des versions à installer qui soient compatibles entre elles. Il possède aussi un certain nombre de fonctionnalités standard pour un gestionnaire de paquets, comme désinstaller un paquet, lister les paquets installés, etc.

S’il y a un outil de packaging quasi universel, c’est bien pip. Par exemple, la page de chaque paquet sur PyPI (exemple) affiche une commande pour l’installer, à savoir pip install <paquet>. Quand la documentation d’un paquet donne des instructions d’installation, elles utilisent généralement pip.

De plus, la distribution officielle de Python permet de boostraper très simplement pip avec la commande python -m ensurepip. Cela rend pip très facile à installer, et lui donne un caractère officiel, soutenu par les développeurs de Python, caractère que n’ont pas la plupart des autres outils que je vais mentionner.

Même les autres outils qui installent aussi des paquets depuis le PyPI (comme pipx, Hatch, tox, etc.) le font presque tous en utilisant, en interne, pip (sauf Poetry qui est un peu à part).

Dans l’univers parallèle de Conda et Anaconda, les utilisateurs sont souvent obligés d’utiliser pip dans un environnement Conda parce qu’un paquet donné n’est pas disponible au format Conda (ce qui crée, d’ailleurs, des problèmes de compatibilité, mais c’est un autre sujet).

Les dangers de pip sous Linux

Malheureusement, sous Linux spécifiquement, l’interface en ligne de commande de pip a longtemps été un moyen très facile de se tirer une balle dans le pied. En effet, la commande simple

pip install <paquet>

tentait d’installer le paquet au niveau du système, de manière visible pour tous les utilisateurs de la machine (typiquement dans /usr/lib/pythonX.Y/site-packages/). Bien sûr, il faut des permissions pour cela. Que fait Monsieur Toutlemonde quand il voit « permission denied error » ? Élémentaire, mon cher Watson :

sudo pip install <paquet>

Or, sous Linux, installer des paquets avec pip au niveau du système, c’est mal. Je répète : c’est MAL. Ou plutôt, c’est valable dans 0,1% des cas et dangereux dans 99,9% des cas.

J’insiste : ne faites JAMAIS sudo pip install ou sudo pip uninstall. (Sauf si vous savez parfaitement ce que vous faites et que vous avez scrupuleusement vérifié qu’il n’y a aucun conflit.)

Le souci ? Les distributions Linux contiennent, elles aussi, des paquets écrits en Python, qui sont installés au même endroit que celui dans lequel installe la commande sudo pip install. Pip peut donc écraser un paquet installé par le système avec une version différente du même paquet, potentiellement incompatible avec le reste, ce qui peut avoir des conséquences catastrophiques. Il suffit de penser que DNF, le gestionnaire de paquets de Fedora, est écrit en Python, pour avoir une idée des dégâts potentiels !

Aujourd’hui, heureusement, la commande pip install <paquet> (sans sudo), au lieu d’échouer avec une erreur de permissions, installe par défaut dans un emplacement spécifique à l’utilisateur, typiquement ~/.local/lib/pythonX.Y/site-packages/ (ce qui devait auparavant se faire avec pip install --user <paquet>, l’option --user restant disponible si on veut être explicite). De plus, pip émet un avertissement sous Linux lorsqu’exécuté avec les droits root (source). Ainsi, pip install <paquet> est devenu beaucoup moins dangereux.

Attention, j’ai bien dit moins dangereux… mais dangereux quand même ! Pourquoi, s’il n’efface plus les paquets du système ? Parce que si un paquet est installé à la fois par le système, et par pip au niveau de l’utilisateur, la version de pip va prendre le dessus, car le dossier utilisateur a priorité sur le dossier système. Le résultat est que le conflit, en réalité, persiste : il reste possible de casser un paquet système en installant une version incompatible avec pip au niveau utilisateur. Seulement, c’est beaucoup plus facile à corriger (il suffit d’un rm -rf ~/.local/lib/pythonX.Y/site-packages/*, alors qu’un conflit dans le dossier système peut être quasi irréparable).

La seule option qui soit sans danger est de ne jamais rien installer en dehors d’un environnement virtuel (voir plus bas pour les instructions).

Pour finir, la PEP 668 a créé un mécanisme pour qu’une distribution Linux puisse marquer les dossiers de paquets Python qu’elle contrôle. Pip refuse (par défaut) de modifier ces dossiers et affiche un avertissement qui mentionne les environnements virtuels. Debian (à partir de Debian Bookworm), Ubuntu (à partir d’Ubuntu Lunar) et d’autres distributions Linux, ont choisi de mettre en place cette protection. Donc, désormais, sudo ou pas, pip install en dehors d’un environnement virtuel donne une erreur (on peut forcer l’opération avec l’option --break-system-packages).

En revanche, Fedora n’a pas implémenté la protection, espérant réussir à créer un dossier pour pip qui soit au niveau système mais séparé du dossier de la distribution Linux, pour que pip install soit complètement sûr et qu’il n’y ait pas besoin de cette protection. Je recommande la présentation de Miro Hrončok à la conférence PyCon polonaise en janvier 2023, qui explique le casse-tête dans les menus détails. Petite citation en avant-goût : « The fix is quite trivial when you design it, and it only strikes back when you actually try to do it ».

Pip est un outil de bas niveau

Pip a une autre chausse-trappe qui est surprenant quand on est habitué au gestionnaire de paquets d’une distribution Linux. Petite illustration :

$ python -m venv my-venv/ # crée un environnement isolé vide pour la démonstration

$ source my-venv/bin/activate # active l’environnement

$ pip install myst-parser
[...]
Successfully installed MarkupSafe-2.1.3 Pygments-2.16.1 alabaster-0.7.13 [...]
[...]

$ pip install mdformat-deflist
[...]
Installing collected packages: markdown-it-py, mdit-py-plugins, mdformat, mdformat-deflist [...]
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
myst-parser 2.0.0 requires markdown-it-py~=3.0, but you have markdown-it-py 2.2.0 which is incompatible.
myst-parser 2.0.0 requires mdit-py-plugins~=0.4, but you have mdit-py-plugins 0.3.5 which is incompatible.
Successfully installed markdown-it-py-2.2.0 mdformat-0.7.17 mdformat-deflist-0.1.2 mdit-py-plugins-0.3.5 [...]

$ echo $?
0

Comme on peut le voir, la résolution des dépendances par pip ne prend pas en compte les paquets déjà installés dans l’environnement. Autrement dit, pour installer un paquet X, pip va simplement regarder quelles sont les dépendances de X (y compris les dépendances transitives), trouver un ensemble de versions qui soient compatibles entre elles, et les installer. Pip ne vérifie pas que les versions des paquets sont aussi compatibles avec ceux qui sont déjà installés. Ou plutôt, il les vérifie, mais seulement après avoir fait l’installation, à un moment où le mal est déjà fait, et uniquement pour afficher un avertissement. Dans l’exemple ci-dessus, on installe d’abord myst-parser, dont la dernière version dépend de markdown-it-py version 3.x, puis on installe mdformat-deflist, qui dépend de markdown-it-py version 1.x ou 2.x. En installant mdformat-deflist, Pip installe aussi, comme dépendance, markdown-it-py 2.x, ce qui casse le myst-parser installé précédemment.

Ceci n’est naturellement pas du goût de tout le monde (je me rappelle d’ailleurs d’une enquête utilisateur faite par les développeurs de Pip il y a quelques années, où ils posaient la question de savoir ce que Pip devait faire dans cette situation). La morale est que pip est surtout un outil conçu pour créer un environnement virtuel où se trouvent toutes les dépendances dont on a besoin, pas pour s’en servir comme de apt ou dnf, en installant et désinstallant manuellement des dépendances. Et surtout, que pip install X; pip install Y n’est absolument pas équivalent à pip install X Y, et c’est la seconde forme qui est correcte.

Les environnements virtuels : venv, virtualenv, pipx

Les environnements virtuels permettent de travailler avec des ensembles de paquets différents, installés de façon indépendante entre eux. L’outil d’origine pour les créer est virtualenv. Néanmoins, le plus utilisé aujourd’hui est venv, qui est une version réduite de virtualenv intégrée à la bibliothèque standard. Malheureusement, venv est plus lent et n’a pas toutes les fonctionnalités de virtualenv, qui reste donc utilisé également…

Pour créer un environnement virtuel (avec venv), on exécute :

python -m venv nom-de-l-environnement

Cela crée un dossier nom-de-l-environnement/. Chaque environnement est donc stocké dans un dossier. À l’intérieur de ce dossier se trouve notamment un sous-dossier bin/ avec des exécutables :

un exécutable python, qui ouvre un interpréteur Python ayant accès aux paquets de l’environnement virtuel (et, par défaut, seulement eux),
un exécutable pip, qui installe les paquets à l’intérieur de l’environnement.

De plus, pour simplifier l’utilisation dans un shell, on peut « activer » l’environnement, avec une commande qui dépend du shell. Par exemple, sous les shells UNIX classiques (bash, zsh), on exécute

source nom-de-l-environnement/bin/activate

Cette commande modifie la variable PATH pour y ajouter nom-de-l-environnement/bin/ afin que (par exemple) la commande python invoque nom-de-l-environnement/bin/python.

Malgré cela, les environnements virtuels restent un niveau de confort en dessous du Python du système, puisqu’il faut activer un environnement avant de s’en servir, ou écrire à chaque fois le chemin dossier-environnement/bin/. Bien sûr, il faut aussi mémoriser les commandes, et puis c’est si facile de faire pip install dans l’environnement global (non virtuel). Donc, beaucoup n’y prêtent malheureusement pas attention et installent au niveau global, ce qui cause des conflits de dépendances (c’est maintenant refusé par défaut sous Debian et dérivés, comme je l’expliquais dans la section précédente, mais c’est toujours majoritaire sous macOS et Windows).

C’est aussi pour rendre plus pratiques les environnements virtuels qu’existent pléthore d’outils qui les créent et/ou activent pour vous. Je termine avec l’un de ces outils, lié à la fois à pip et aux environnements virtuels, j’ai nommé pipx. À première vue, pipx a une interface qui ressemble à celle de pip, avec par exemple des sous-commandes pipx install, pipx uninstall et pipx list. Mais, à la différence de pip, qui installe un paquet dans un environnement déjà créé, pipx va, pour chaque paquet installé, créer un nouvel environnement virtuel dédié. Pipx est principalement destiné à installer des outils dont l’interface est en ligne de commande, pas sous forme d’un module importable en Python. Pipx utilise pip, pour ne pas trop réinventer la roue quand même. Au final,

$ pipx install pycowsay

revient à quelque chose comme

$ python -m venv ~/.local/pipx/pycowsay/
$ ~/.local/pipx/pycowsay/bin/pip install pycowsay
$ ln -s ~/.local/pipx/pycowsay/bin/pycowsay ~/.local/bin/pycowsay

Pour résumer, pipx permet d’installer des outils en ligne de commande, de manière isolée, qui n’interfèrent pas avec le système ou entre eux, sans avoir à gérer les environnements virtuels soi-même.

L’invocation d’un build backend : build

Pour déposer son projet sur PyPI, il faut d’abord obtenir deux fichiers : une sdist (source distribution), qui est essentiellement une archive .tar.gz du code avec des métadonnées ajoutées, et un paquet installable au format wheel, d’extension .whl. L’outil build sert à générer ces deux fichiers. Il s’invoque comme ceci, dans le dossier du code source :

python -m build

Petit exemple dans le dépôt de Sphinx (l’outil de documentation le plus répandu dans le monde Python) :

$ python -m build
* Creating venv isolated environment...
* Installing packages in isolated environment... (flit_core>=3.7)
* Getting build dependencies for sdist...
* Building sdist...
* Building wheel from sdist
* Creating venv isolated environment...
* Installing packages in isolated environment... (flit_core>=3.7)
* Getting build dependencies for wheel...
* Building wheel...
Successfully built sphinx-7.3.0.tar.gz and sphinx-7.3.0-py3-none-any.whl

$ ls dist/
sphinx-7.3.0-py3-none-any.whl  sphinx-7.3.0.tar.gz

Comme on peut le comprendre, build est un outil très simple. L’essentiel de sa documentation tient en une courte page. Il crée un environnement virtuel pour installer le build backend, en l’occurrence Flit, puis se contente d’invoquer celui-ci.

Le transfert sur PyPI : twine

À l’image de build, twine est un outil fort simple qui remplit une seule fonction et la remplit bien : déposer la sdist et le wheel sur PyPI (ou un autre dépôt de paquets). En continuant l’exemple précédent, on écrirait :

twine upload dist/*

Après avoir fourni un login et mot de passe, le projet est publié, il peut être installé avec pip, et possède sa page https://pypi.org/project/nom-du-projet.

La configuration d’un projet : le fichier `pyproject.toml`

pyproject.toml est le fichier de configuration adopté par à peu près tous les outils de packaging, ainsi que de nombreux outils qui ne sont pas liés au packaging (par exemple les linters comme Ruff, les auto-formateurs comme Black ou le même Ruff, etc.). Il est écrit dans le langage de configuration TOML. On a besoin d’un pyproject.toml pour n’importe quel projet publié sur PyPI, et même, souvent, pour les projets qui ne sont pas distribués sur PyPI (comme pour configurer Ruff).

Dans ce fichier se trouvent trois sections possibles — des « tables », en jargon TOML. La table [build-system] détermine le build backend du projet (je reviens plus bas sur le choix du build backend). La table [project] contient les informations de base, comme le nom du projet, la version, les dépendances, etc. Quant à la table [tool], elle est utilisée via des sous-tables [tool.<nom de l'outil>] : tout outil peut lire de la configuration dans sa sous-table dédiée. Rien n’est standardisé par des spécifications PyPA dans la table [tool], chaque outil y fait ce qu’il veut.

Avant qu’on me dise que pyproject.toml est mal documenté, ce qui a pu être vrai, je précise que des efforts ont été faits à ce niveau dans les dernières semaines, par moi et d’autres, ce qui donne un guide du pyproject.toml normalement complet et compréhensible, ainsi qu’une explication sur ce qui est déprécié ou non concernant setup.py et un guide sur la migration de setup.py vers pyproject.toml. Tout ceci réside sur packaging.python.org, qui est un site officiel de la PyPA rassemblant des tutoriels, guides et spécifications techniques.

Les build backends pour code Python pur

Le build backend est chargé de générer les sdists et les wheels que l’on peut ensuite mettre sur PyPI avec twine ou autre. Il est spécifié dans le fichier pyproject.toml. Par exemple, pour utiliser Flit, la configuration est :

[build-system]
requires = ["flit_core>=3.7"]
build-backend = "flit_core.buildapi"

requires est la liste des dépendances (des paquets sur PyPI), et build-backend est le nom d’un module (qui doit suivre une interface standardisée).

Il peut sembler étrange qu’il faille, même pour un projet simple, choisir son build backend. Passons donc en revue les critères de choix : de quoi est responsable le build backend ?

D’abord, il doit traduire les métadonnées du projet. En effet, dans les sdists et wheels, les métadonnées sont encodées dans un format un peu étrange, à base de MIME, qui est conservé au lieu d’un format plus moderne comme TOML ou JSON, pour des raisons de compatibilité. La plupart des build backends se contentent de prendre les valeurs dans la table [project] du pyproject.toml et de les copier directement sous la bonne forme, mais setuptools permet aussi de configurer les métadonnées via setup.py ou setup.cfg, également pour préserver la compatibilité, et il y a aussi des build backends comme Poetry qui n’ont pas adopté la table [project] (j’y reviens dans la section sur Poetry).

De plus, les build backends ont souvent des façons de calculer dynamiquement certaines métadonnées, typiquement la version, qui peut être lue depuis un attribut __version__, ou déterminée à partir du dernier tag Git.

C’est aussi le build backend qui décide des fichiers du projet à inclure ou exclure dans la sdist et le wheel. En particulier, on trouve généralement des options qui permettent d’inclure des fichiers autres que .py dans le wheel (c’est le wheel qui détermine ce qui est installé au final, alors que la sdist peut aussi contenir les tests etc.). Cela peut servir, par exemple, aux paquets qui doivent être distribués avec des icônes, des données en JSON, des templates Django…

Enfin, s’il y a des extensions en C, C++, Rust ou autre, le build backend est chargé de les compiler.

Il existe aujourd’hui de nombreux build backends. Beaucoup sont spécifiques à un type d’extensions compilées, ils sont présentés dans la troisième dépêche. Voici les build backends principaux pour du code Python pur.

setuptools

C’est le build backend historique. Il reste très largement utilisé.

Avant qu’arrive pyproject.toml, il n’y avait qu’un build backend, setuptools, et il était configuré soit par le setup.py, soit par un fichier en syntaxe INI, nommé setup.cfg (qui est l’ancêtre de pyproject.toml). Ainsi, il existe aujourd’hui trois manières différentes de configurer setuptools, à savoir setup.py, setup.cfg et pyproject.toml. On rencontre les trois dans les projets existants. La façon recommandée aujourd’hui est pyproject.toml pour tout ce qui est statique, sachant que setup.py, qui est écrit en Python, peut toujours servir s’il y a besoin de configuration programmable.

Aujourd’hui, setuptools ne se veut plus qu’un build backend, mais historiquement, en tant que descendant de distutils, il a beaucoup de fonctionnalités, désormais dépréciées, pour installer des paquets ou autres. On peut se faire une idée de l’ampleur des évolutions qui ont secoué le packaging au fil des années en parcourant l’abondante documentation des fonctionnalités obsolètes, notamment cette page, celle-ci ou encore celle-là.

Flit

Flit est l’exact opposé de setuptools. C’est le build backend qui vise à être le plus simple et minimal possible. Il n’y a pratiquement pas de configuration autre que la configuration standardisée des métadonnées dans la table [project] du pyproject.toml.

Flit se veut volontairement inflexible (« opinionated »), pour qu’il n’y ait pas de choix à faire. Avec Flit, un projet appelé nom-projet doit obligatoirement fournir un module et un seul, soit nom_projet.py, soit nom_project/. De même, il est possible d’inclure des fichiers autres que .py, mais ils doivent obligatoirement se trouver tous dans un dossier dédié au même niveau que le pyproject.toml.

Flit dispose aussi d’une interface en ligne de commande minimale, avec des commandes flit build (équivalent de python -m build), flit publish (équivalent de twine upload), flit install (équivalent de pip install .), et flit init (qui initialise un projet).

Hatchling

Hatchling est le build backend associé à Hatch, un outil tout-en-un dont il sera question plus loin.

Contrairement à setuptools, il est plutôt facile d’utilisation, et il fait plus souvent ce qu’on veut par défaut. Contrairement à Flit, il offre aussi des options de configuration plus avancées (comme pour inclure plusieurs modules dans un paquet), ainsi que la possibilité d’écrire des plugins.

PDM-Backend

De même que hatchling est associé à Hatch, PDM-Backend est associé à PDM. Je n'en ai pas d'expérience, mais à lire sa documentation, il me semble plus ou moins équivalent en fonctionnalités à hatchling, avec des options un peu moins fines.

Poetry-core

Comme les deux précédents, Poetry-core est associé à un outil plus vaste, à savoir Poetry.

Par rapport à hatchling et PDM-backend, il est moins sophistiqué (il ne permet pas de lire la version depuis un attribut dans le code ou depuis un tag Git).

La gestion des versions de Python : pyenv

L’une des difficultés du packaging Python est que l’interpréteur Python lui-même n’est généralement pas compilé upstream et téléchargé depuis le site officiel, du moins pas sous Linux (c’est davantage le cas sous Windows, et plus ou moins le cas sous macOS). L’interpréteur est plutôt fourni de l’extérieur, à savoir, sous Linux, par le gestionnaire de paquets de la distribution, ou bien, sous macOS, par XCode, Homebrew ou MacPorts. Cela peut aussi être un Python compilé à partir du code source sur la machine de l’utilisateur.

Ce modèle est différent d’autres langages comme Rust, par exemple. Pour installer Rust, la plupart des gens utilisent Rustup, un script qui télécharge des exécutables statiques compilés upstream (le fameux curl | bash tant décrié…).

Le but de pyenv est de simplifier la gestion des versions de Python. On exécute, par exemple, pyenv install 3.10.2 pour installer Python 3.10.2. Comme pyenv va compiler le code source, il faut quand même installer soi-même les dépendances (avec leurs en-têtes C).

Un outil de test et d’automatisation : tox

À partir du moment où un projet grossit, il devient souvent utile d’avoir de petits scripts qui automatisent des tâches courantes, comme exécuter les tests, mettre à jour tel fichier à partir de tel autre, ou encore compiler des catalogues de traduction en format MO à partir des fichiers PO. Il devient également nécessaire de tester le projet sur différentes versions de Python, ou encore avec différentes versions des dépendances.

Tout cela est le rôle de tox. Il se configure avec un fichier tox.ini. Voici un exemple tiré de Pygments:

[tox]
envlist = py

[testenv]
description =
    run tests with pytest (you can pass extra arguments for pytest,
    e.g., "tox -- --update-goldens")
deps =
    pytest >= 7.0
    pytest-cov
    pytest-randomly
    wcag-contrast-ratio
commands =
    pytest {posargs}
use_develop = True

On peut avoir plusieurs sections [testenv:xxx] qui définissent des environnements virtuels. Chaque environnement est créé avec une version de Python ainsi qu’une certaine liste de dépendances, et peut déclarer des commandes à exécuter. Ces commandes ne passent pas par un shell, ce qui garantit que le tox.ini reste portable.

Interlude : vous avez dit lock file?

Pour faire simple, un lock file est un fichier qui décrit de manière exacte un environnement de sorte qu’il puisse être reproduit. Prenons un exemple. Imaginons une application Web déployée sur plusieurs serveurs, qui a besoin de la bibliothèque requests. Elle va déclarer cette dépendance dans sa configuration. Éventuellement, elle fixera une borne sur la version (par exemple requests>=2.31), pour être sûre d’avoir une version compatible. Mais le paquet requests a lui-même des dépendances. On souhaiterait que l’environnement soit vraiment reproductible — que des serveurs différents n’aient pas des versions différentes des dépendances, même si les environnements sont installés à des moments différents, entre lesquels des dépendances publient des nouvelles versions. Sinon, on risque des bugs difficiles à comprendre qui ne se manifestent que sur l’un des serveurs.

La même problématique se pose pour développer une application à plusieurs. Sauf si l’application doit être distribuée dans des environnements variés (par exemple empaquetée par des distributions Linux), il ne vaut pas la peine de s’embarrasser de versions différentes des dépendances. Il est plus simple de fixer toutes les versions pour tout le monde.

Dans la vraie vie, une application peut avoir des centaines de dépendances, dont quelques-unes directes et les autres indirectes. Il devient très fastidieux de maintenir à la main une liste des versions exactes de chaque dépendance.

Avec un lock file, on s’assure de geler un ensemble de versions de tous les paquets qui sera le même pour tous les contributeurs, et pour tous les déploiements d’une application. On sépare, d’un côté, la déclaration des dépendances directes minimales supposées compatibles avec l’application, écrite à la main, et de l’autre côté, la déclaration des versions exactes de toutes les dépendances, générée automatiquement. Concrètement, à partir de la contrainte requests>=2.31, un générateur de lock file pourrait écrire un lock file qui fixe les versions certifi==2023.11.17, charset-normalizer==3.3.2, idna==3.4, requests==2.31.0, urllib3==2.1.0. À la prochaine mise à jour du lock file, certaines de ces versions pourraient passer à des versions plus récentes publiées entre-temps.

Le concept de lock file est en revanche beaucoup plus discutable pour une bibliothèque (par opposition à une application), étant donné qu’une bibliothèque est faite pour être utilisée dans d’autres projets, et que si un projet a besoin des bibliothèques A et B, où A demande requests==2.31.0 alors que B demande requests==2.30.0, il n’y a aucun moyen de satisfaire les dépendances. Pour cette raison, une bibliothèque doit essayer de minimiser les contraintes sur ses dépendances, ce qui est fondamentalement opposé à l’idée d’un lock file.

Il existe plusieurs outils qui permettent de générer et d’utiliser un lock file. Malheureusement, l’un des plus gros problèmes actuels du packaging Python est le manque criant, sinon d’un outil, d’un format de lock file standardisé. Il y a eu une tentative avec la PEP 665, rejetée par manque de consensus (mais avant qu’on soupire qu’il suffisait de se mettre d’accord : il y a de vraies questions techniques qui se posent, notamment sur l’adoption d’un standard qui ne permet pas de faire tout ce que font certains outils existants, qui risquerait de fragmenter encore plus au lieu d’aider).

Un gestionnaire de lock file : pip-tools

pip-tools est un outil assez simple pour générer et utiliser un lock file. Il se compose de deux parties, pip-compile et pip-sync.

La commande pip-compile, prend un ensemble de déclarations de dépendances, soit dans un pyproject.toml, soit dans un fichier spécial requirements.in. Elle génère un fichier requirements.txt qui peut être installé par pip.

Quant à la commande pip-sync, c’est simplement un raccourci pour installer les dépendances du requirements.txt.

Les locks files sont donc des fichiers requirements.txt, un format pas si bien défini puisqu’un requirements.txt est en fait essentiellement une série d’arguments et d’options en ligne de commande à passer à pip.

Les outils « tout-en-un »

Face à la prolifération d’outils à installer et mémoriser, certains ont essayé de créer une expérience plus cohérente avec des outils unifiés. Malheureusement, ce serait trop simple s’ils s’étaient accordés sur un projet commun…

Poetry

Poetry est un outil un peu à part qui fait à peu près tout par lui-même.

Poetry se destine aux développeurs de bibliothèques et d’applications. Toutefois, en pratique, il est plutôt orienté vers les applications.

La configuration se fait entièrement dans le fichier pyproject.toml. Poetry s’utilise toujours avec son build backend Poetry-core, donc la partie [build-system] du pyproject.toml est configurée comme ceci :

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

En revanche, contrairement à la plupart des autres build backends, Poetry n’accepte pas la configuration dans la table [project]. À la place, il faut écrire les métadonnées sur le projet (nom, version, mainteneurs, etc.) dans la table [tool.poetry], dans un format différent du format standard.

La particularité de Poetry qui le rend à part est d’être centré profondément sur le concept de lock file, d’insister fortement sur le Semantic Versioning, et d’avoir son propre résolveur de dépendances. Poetry n’installe jamais rien dans l’environnement virtuel du projet avant d’avoir généré un lock file qui trace les versions installées. Sa configuration a aussi des raccourcis typiques du semantic versioning, comme la syntaxe nom_du_paquet = "^3.4", qui dans la table [project] s’écrirait plutôt "nom_du_paquet >= 3.4, < 4.

(Ironiquement, les versions de Poetry lui-même ne suivent pas le Semantic Versioning.)

Je ne vais pas présenter les commandes de Poetry une par une car cette dépêche est déjà bien trop longue. Je renvoie à la documentation. Disons simplement qu’un projet géré avec Poetry se passe de pip, de build, de twine, de venv et de pip-tools.

PDM

Je l’avoue, je connais mal PDM. D’après ce que j’en ai compris, il est assez semblable à Poetry dans son interface, mais suit tout de même plus les standards, en mettant sa configuration dans la table [project], et en utilisant le résolveur de dépendances de pip. (Je parlerai tout de même, dans la quatrième dépêche, de la motivation à l’origine du développement de PDM, qui cache toute une histoire. Pour ceux qui ont compris, oui, c’est bien résumé par un nombre qui est multiple de 97.)

Hatch

Hatch est plus récent que Poetry et PDM. (Il n’est pas encore au niveau de Poetry en termes de popularité, mais loin devant PDM.) Il est encore en développement rapide.

Comparé à Poetry et PDM, il ne gère pas, pour l’instant, les lock files. (Ici aussi, il y a une histoire intéressante : l’auteur a d’abord voulu attendre que les discussions de standardisation aboutissent à un format commun, mais vu l’absence de progrès, il a fait savoir récemment qu’il allait implémenter un format non standardisé, comme Poetry et PDM le font déjà.)

En contrepartie, Hatch gère aussi les versions de Python. Il est capable d’installer ou de désinstaller une version très simplement, sachant que, contrairement à pyenv, il ne compile pas sur la machine de l’utilisateur mais télécharge des versions précompilées (beaucoup plus rapide, et aucune dépendance à installer soi-même). Il a aussi une commande fmt pour reformater le projet (plutôt que de définir soi-même un environnement pour cela dans Poetry ou PDM), et il est prévu qu’il gagne bientôt des commandes comme hatch test et hatch doc également.

De plus, dans Poetry, lorsque l’on déclare, par exemple, un environnement pour compiler la documentation, avec une dépendance sur sphinx >= 7, cette dépendance est résolue en même temps que les dépendances principales du projet. Donc, si votre générateur de documentation demande une certaine version, mettons, de Jinja2 (ou n’importe quel autre paquet), vous êtes forcé d’utiliser la même version pour votre propre projet, même si l’environnement pour exécuter votre projet n’a rien à voir avec l’environnement pour générer sa documentation. C’est la même chose avec PDM. Je trouve cette limitation assez frustrante, et Hatch n’a pas ce défaut.

La création d’exécutables indépendants et installeurs : PyInstaller, cx_freeze, briefcase, PyOxidizer (etc.)

Distribuer son projet sur PyPI est bien beau, mais pour installer un paquet du PyPI, il faut d’abord avoir Python et savoir se servir d’un terminal pour lancer pip. Quid de la distribution d’une application graphique à des gens qui n’ont aucune connaissance technique ?

Pour cela, il existe une pléthore d’outils qui créent des installeurs, contenant à la fois Python, une application, ses dépendances, une icône d’application, et en bref, tout ce qu’il faut pour satisfaire les utilisateurs qui n’y comprennent rien et réclament juste une « application normale » avec un « installeur normal », un appli-setup.exe ou Appli.dmg. Les plus connus sont PyInstaller et py2exe. Plus récemment est aussi apparu briefcase.

Il y a aussi d’autres outils qui ne vont pas jusqu’à créer un installeur graphique, mais se contentent d’un exécutable qui peut être lancé en ligne de commande. Ce sont notamment cx_freeze et PyOxidizer, mais il y en a bien d’autres.

Malheureusement, toute cette classe d’usages est l’un des gros points faibles de l’écosystème actuel. PyInstaller, par exemple, est fondé sur des principes assez douteux qui datent d’une époque où le packaging était beaucoup moins évolué qu’aujourd’hui (voir notamment ce commentaire). Pour faire simple, PyInstaller détecte les import dans le code pour trouver les fichiers à inclure dans l’application, au lieu d’inclure toutes les dépendances déclarées par les mainteneurs. Il semble que briefcase soit meilleur de ce point de vue.

De manière plus générale, embarquer un interpréteur Python est techniquement compliqué, notamment à cause de l’interaction avec des bibliothèques système (comme OpenSSL), et chacun de ces projets résout ces difficultés d’une manière différente qui a ses propres limitations.

Conda, un univers parallèle

Comme expliqué dans la première dépêche sur l’historique du packaging, Conda est un outil entièrement indépendant de tout le reste. Il ne peut pas installer de paquets du PyPI, son format de paquet est différent, ses environnements virtuels sont différents. Il est développé par une entreprise, Anaconda Inc (mais publié sous une licence libre). Et surtout, bien que chacun puisse publier des paquets sur anaconda.org, il reste principalement utilisé à travers des dépôts de paquets comprenant plusieurs milliers de paquets, qui sont gérés non pas par les auteurs du code concerné, mais par des mainteneurs propres au dépôt de paquets, à la manière d’une distribution Linux, ou de Homebrew et MacPorts sous macOS. En pratique, les deux dépôts principaux sont Anaconda, qui est maintenu par Anaconda Inc, et conda-forge, maintenu par une communauté de volontaires.

Quelques outils gravitent autour de Conda (mais beaucoup moins que les outils compatibles PyPI, car Conda est plus unifié). Je pense notamment à Condax, qui est à Conda ce que pipx est à pip. Il y a aussi conda-lock pour les lock files.

Grâce à son modèle, Conda permet une distribution très fiable des extensions C et C++, ce qui constitue son atout principal. Un inconvénient majeur est le manque de compatibilité avec PyPI, qui reste la source unique pour la plupart des paquets, Conda n’ayant que les plus populaires.

Petite comparaison des résolveurs de dépendances

Les résolveurs de dépendances sont des composants invisibles, mais absolument cruciaux des systèmes de packaging. Un résolveur de dépendances prend un ensemble de paquets, et de contraintes sur ces paquets, de la forme « l’utilisateur demande le paquet A version X.Y au minimum et version Z.T au maximum », ou « le paquet A version X.Y dépend du paquet B version Z.T au minimum et U.V au maximum ». Il est chargé de déterminer un ensemble de versions compatibles, si possible récentes.

Cela paraît simple, et pourtant, le problème de la résolution de dépendances est NP-complet (c’est facile à démontrer), ce qui signifie que, sauf à prouver fausse l'hypothèse du temps exponentiel (et si vous le faites, vous deviendrez célèbre et couronné de gloire et du prix Turing), il n’existe pas d’algorithme pour le résoudre qui ait une complexité meilleure qu’exponentielle. Les algorithmes utilisés en pratique se fondent soit sur des heuristiques, soit sur une traduction en problème SAT et appel d’un SAT-solveur. Le bon résolveur est celui qui réussira à résoudre efficacement les cas rencontrés en pratique. Pour revenir à Python, il y a aujourd’hui trois résolveurs de dépendances principaux pour les paquets Python.

Le premier est celui de pip, qui est implémenté dans resolvelib. Il utilise des heuristiques relativement simples. Historiquement, il s’est construit sur une contrainte forte : jusqu’à récemment (PEP 658), il n’y avait aucun moyen sur PyPI de télécharger seulement les métadonnées d’un paquet sans télécharger le paquet entier. Donc, il n’était pas possible d’obtenir tout le graphe de dépendances entier avant de commencer la résolution, car cela aurait nécessité de télécharger le code entier de toutes les versions de chaque dépendance. Or, il n’y a aucun solveur SAT existant (à ma connaissance) qui permette de modifier incrémentalement le problème. Par conséquent, pip était de toute façon forcé d’adopter une stratégie ad-hoc. La contrainte a été levée, mais l’algorithme est resté.

Le deuxième résolveur est celui de Conda. (En fait, le résolveur est en train de changer, mais l’ancien et le nouveau sont similaires sur le principe.) Contrairement à pip, Conda télécharge à l’avance un fichier qui donne les dépendances de chaque version de chaque paquet, ce qui lui permet de traduire le problème de résolution entier en problème SAT et d’appliquer un solveur SAT.

Enfin, le troisième résolveur fait partie de Poetry. Si j’ai bien compris ceci, il utilise l’algorithme PubGrub, qui ne traduit pas le problème en SAT, mais le résout plutôt avec une méthode inspirée de certains solveurs SAT.

En pratique, dans mon expérience, le solveur de pip se montre rapide la plupart du temps (sauf dans les cas vraiment complexes avec beaucoup de dépendances et de contraintes).

Toujours dans mon expérience, la résolution de dépendances dans Conda est en revanche franchement lente. À sa décharge, je soupçonne que le résolveur lui-même n’est pas spécialement lent (voire, plus rapide que celui de pip ? je ne sais pas), mais comme Conda a pour principe de ne prendre quasiment rien dans le système, en ayant des paquets comme wget, freetype, libxcb, pcre2, etc. etc. etc., certains paquets ont un nombre absolument effrayant de dépendances. Par exemple, il y a quelque temps, j’ai eu à demander à conda-lock un environnement satisfaisant les contraintes suivantes :

- pyqt=5.15.9
- sip=6.7.11
- pyqt-builder=1.15.2
- cmake=3.26.4
- openjpeg=2.5.0
- jpeg=9e
- compilers=1.6.0
- boost-cpp
- setuptools=68.0.0
- wheel

Sur mon ordinateur, il faut environ 7 minutes pour que Conda calcule l’environnement résultant — j’insiste sur le fait que rien n’est installé, ce temps est passé uniquement dans le résolveur de dépendances. Le lock file créé contient environ 250 dépendances (!).

À titre illustratif : « Conda has gotten better by taking more shortcuts and guessing things (I haven't had a 25+ hour solve in a while) » — Henry Schreiner

Quant au résolveur de Poetry, même si je n’ai jamais utilisé sérieusement Poetry, je crois savoir que sa lenteur est l’une des objections les plus fréquentes à cet outil. Voir par exemple ce bug avec 335 👍. (Je trouve aussi révélateur que sur les premiers résultats renvoyés par une recherche Google de « poetry dependency resolver », une moitié environ se plaigne de la lenteur du résolveur.)

D’un autre côté, le solveur de Poetry n’est appelé que lorsque le lock file est mis à jour, donc beaucoup moins souvent que celui de pip ou même Conda. Il y a un vrai compromis à faire : le résolveur de Poetry se veut plus précis (il est censé trouver plus souvent une solution avec des versions récentes), mais en contrepartie, la mise à jour du lock file peut prendre, apparemment, une dizaine de minutes dans certains cas.

Conclusion et avis personnels

Je termine en donnant mes choix très personnels et partiellement subjectifs, avec lesquels tout le monde ne sera pas forcément d’accord.

D’abord, il faut une manière d’installer des outils en ligne de commande distribués sous forme de paquets Python. Il est sage de donner à chacun son environnement virtuel pour éviter que leurs dépendances n’entrent en conflit, ce qui peut arriver très vite. Pour cela, on a essentiellement le choix entre pipx, ou créer à la main un environnement virtuel à chaque fois. Sans hésiter, je choisis pipx.

(Il y a un problème de boostrap parce que pipx est lui-même un outil du même genre. La solution consiste à l’installer avec un paquet système, que la plupart des distributions fournissent, normalement sous le nom python3-pipx.)

Ensuite, pour travailler sur un projet, on a le choix entre utiliser build et twine à la main pour générer la sdist et le wheel et les distribuer sur PyPI, ou bien utiliser un outil plus unifié, soit Flit, soit Poetry, soit PDM, soit Hatch. Dans le premier cas, on peut utiliser n’importe quel build backend, dans le deuxième, on est potentiellement restreint au build backend associé à l’outil unifié (c’est le cas avec Flit et Poetry, mais pas avec PDM, et plus avec Hatch depuis très récemment).

Parlons d’abord du build backend. À vrai dire, lorsque les builds backends ont été introduits (par la PEP 517, voir dépêche précédente), la motivation était largement de permettre l’émergence d’alternatives à setuptools au vu du triste état de setuptools. L’objectif est atteint, puisqu’il y a désormais des alternatives mille fois meilleures. L’ennui, c’est qu’il y a aussi un peu trop de choix. Donc, comparons.

D’abord, il y a setuptools. Sa configuration est franchement compliquée, par exemple je ne comprends pas précisément les douze mille options de configuration qui contrôlent les modules qui sont inclus dans les wheels. De plus, setuptools est vraiment excessivement verbeux. Dans le dépôt de Pygments, un module dont je suis mainteneur, python -m build | wc -l comptait 4190 lignes de log avec setuptools, à comparer à 10 lignes depuis que nous sommes passés à hatchling. Mais surtout, le problème avec setuptools, c’est qu’il y a mille et une fonctionnalités mutantes dont on ne sait pas très bien si elles sont obsolètes, et la documentation est, pour moi, tout simplement incompréhensible. Entendons-nous bien : j’ai beaucoup de respect pour les gens qui maintiennent setuptools, c’est absolument essentiel vu le nombre de paquets qui utilisent setuptools parce que c’était historiquement le seul outil, mais aujourd’hui, peu contestent que setuptools est moins bon qu’à peu près n’importe quel build backend dans la concurrence, et on ne peut pas le simplifier, justement à cause de toute la compatibilité à garder.

Alors… Flit ? Pour les débutants, ce n’est pas mal. Mais la force de Flit, son inflexibilité, est aussi son défaut. Exemple ici et là où, suite à un commentaire de Ploum sur la dépêche précédente, je l’ai aidé à résoudre son problème de packaging, dont la racine était que Flit ne permet tout simplement pas d’avoir plusieurs modules Python dans un même paquet.

Alors… Poetry-core ? PDM-backend ? Hatchling ? Les différences sont moins marquées, donc parlons un peu des outils unifiés qui leur sont associés.

D’abord, que penser de Poetry ? Je précise que ne l’ai jamais utilisé moi-même sur un vrai projet. À ce que j’en ai entendu, la plupart de ceux qui l’utilisent l’apprécient et le trouvent plutôt intuitif. Par ailleurs, comme décrit plus haut, il a son propre résolveur de dépendances, et celui-ci est particulièrement lent au point que la génération du lock file peut prendre du temps. Soit. Mais je suis un peu sceptique à cause de points plus fondamentaux, notamment le fait que les dépendances de votre générateur de documentation contraignent celles de votre projet, ce que je trouve assez idiot. Je recommande aussi ces deux posts très détaillés sur le blog d’Henry Schreiner : Should You Use Upper Bound Version Constraints? et Poetry versions. Pour faire court, Poetry incite fortement à mettre des contraintes de version maximum (comme jinja2 < 3), ce qui est problématique quand les utilisateurs de Poetry se mettent à en abuser sans s’en rendre compte. Et il a aussi des opinions assez spéciales sur la résolution de dépendances, par exemple il vous force à mettre une contrainte < 4 sur Python lui-même dès qu’une de vos dépendances le fait, alors que tout projet Poetry le fait par défaut. J’ajoute le fait qu’on ne peut pas utiliser un autre build backend avec Poetry que Poetry-core. En corollaire, on ne peut pas utiliser Poetry sur un projet si tout le projet n’utilise pas Poetry, ce qui implique de changer des choses pour tous les contributeurs (alors que PDM et Hatch peuvent fonctionner avec un build backend différent). C’est pour moi un gros point noir.

Alors… PDM ? Honnêtement, je n’en ai pas assez d’expérience pour juger vraiment. Je sais qu’il corrige la plupart des défauts de Poetry, mais garde le « défaut du générateur de documentation ».

Alors… Hatch ? C’est celui que j’utilise depuis quelques mois, et jusqu’ici, j’en suis plutôt satisfait. C’est un peu dommage qu’il n’ait pas encore les lock files, mais je n’en ai pas besoin pour mes projets.

Je n’utilise pas pyenv. Déjà avant Hatch, je trouvais qu’il représentait trop de travail à configurer par rapport au service rendu, que je peux facilement faire à la main avec ./configure && make dans le dépôt de Python. Et depuis que j’utilise Hatch, il le fait pour moi, sans avoir à compiler Python.

De même, je n’utilise plus tox, je fais la même chose avec Hatch (avec la nuance que si j’ai déjà tanné mes co-mainteneurs pour remplacer make par tox, j’hésite à re-changer pour Hatch…). J’ai fini par me méfier du format INI, qui est piégeux (c’est subjectif) et mal spécifié (il y en a mille variantes incompatibles).

Donc, en résumé, j’utilise seulement deux outils, qui sont pipx, et Hatch. (Et j’espère n’avoir bientôt plus besoin de pipx non plus.) Mais si vous avez besoin de lock files, vous pourriez remplacer Hatch par PDM.

Je termine la comparaison avec un mot sur Conda. À mon avis, entre écosystème Conda et écosystème PyPI, le choix est surtout pragmatique. Qu’on le veuille ou non, l’écosystème Python s’est historiquement construit autour de PyPI, qui reste prédominant. Malheureusement, la réponse de Conda à « Comment installer dans un environnement Conda un paquet PyPI qui n’est pas disponible au format Conda ? » est « Utilisez pip, mais à vos risques et périls, ce n’est pas supporté », ce qui n’est pas fantastique lorsque l’on a besoin d’un tel paquet (cela arrive très vite). D’un autre côté, pour le calcul scientifique, Conda peut être plus adapté, et il y a des pans entiers de ce domaine, comme le géospatial, qui fonctionnent avec Conda et ne fonctionnent pas du tout avec PyPI.

J’espère que ce très long panorama était instructif et aidait à y voir plus clair dans l’écosystème. Pour la troisième dépêche, je vous proposerai un focus sur la distribution des modules d’extension écrits dans des langages compilés, sur ses difficultés inextricables, et sur les raisons pour lesquelles le modèle de Conda en fait une meilleure plateforme que PyPI pour ces extensions.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

L’installation et la distribution de paquets Python (1/4)

2023-11-06T09:10:39+01:00

Quelques dépêches précédentes ont parlé des outils de packaging Python, comme ici, là ou encore là. Je vais chercher à faire un tour complet de la question, non seulement du point de vue de l’utilisateur qui cherche à comprendre quelle est « la bonne » solution (← ha ha ha rire moqueur…), mais aussi en expliquant les choix qui ont été faits, les évolutions, la structure de la communauté autour des outils, et les critiques qui leur sont souvent adressées, à tort ou à raison.

Sommaire

Les outils historiques : distutils et setuptools
La montée en puissance de pip et PyPI
L’introduction du format « wheel »
Les débuts des environnements virtuels
La création de la Python Packaging Authority (PyPA)
Le développement d’un écosystème alternatif, conda et Anaconda
Les PEP 517 et 518, une petite révolution
La PEP 621, un peu de standardisation
L’émergence d’outils tout-en-un alternatifs
Conclusion

Il est question ici de packaging, terme pris dans un sens très large :

L’installation de paquets,
L’installation de Python lui-même,
L’administration d’environnements isolés,
La gestion de dépendances (lock files notamment),
La distribution de son code, en tant qu’auteur d’un paquet Python,
La compilation de code natif (écrit en C, C++, Rust…) pour être utilisé depuis Python.

Le langage Python, avec son écrasante popularité (premier au classement TIOBE), est vanté pour sa simplicité. Hélas, c’est devenu un lieu commun que cette simplicité ne s’étend pas aux outils de packaging, qui sont tout sauf faciles à maîtriser. Personnellement, j’y ai été confronté en voulant soulager la situation de Frescobaldi, une application écrite avec Python et PyQt. Frescobaldi possède une dépendance qui se trouve concentrer quelques difficultés de distribution et d’installation coriaces, en raison de code C++.

Ce problème d’ensemble a conduit à des évolutions rapides au cours des dernières années, qui tentent de garder un équilibre fragile entre l’introduction de nouvelles méthodes et la compatibilité avec l’existant. Parmi les utilisateurs, une confusion certaine a émergé avec cette cadence des changements, qui fait que des tutoriels écrits il y a quelques années voire quelques mois à peine sont complètement obsolètes, de même que des outils encore récemment recommandés.

Bien que de nombreux progrès soient indéniables, il existe un scepticisme très répandu concernant le degré de fragmentation déconcertant de l’écosystème, qui met l’utilisateur face à un labyrinthe d’outils qui se ressemblent.

Pour illustrer ce labyrinthe, voici une liste des outils que, personnellement, j’utilise ou j’ai utilisé, ou dont j’ai au moins lu sérieusement une partie de la documentation :

pip, pipx, virtualenv, venv, ensurepip, conda, condax, conda-lock, tox, build, twine, setuptools, setuptools-scm, flit, hatch, poetry, pdm, rye, pip-tools, maturin, setuptools-rust, meson-python, scikit-build, sip, pyinstaller, py2app, py2exe, cx_freeze, pyoxidizer, pynsist, briefcase, wheel, repairwheel, auditwheel, delocate, delvewheel, cibuildwheel

Encore une fois, je n’ai mis ceux que je connais. On en trouve encore d’autres ici.

Sans compter quelques outils dont j’ai connaissance mais qui sont aujourd’hui obsolètes ou non-maintenus :

distutils, distutils2, distribute, pyflow, bento, pipenv

Et quelques librairies de plus bas niveau : importlib.metadata, packaging, distlib, installer

Face à cette profusion, le classique aujourd’hui est de citer le XKCD qui va bien, et de renchérir en comparant au langage Rust, connu pour la simplicité de ses outils, à savoir :

cargo, rustup

Et c’est tout. Alors, pourquoi a-t-on besoin de plusieurs douzaines d’outils différents pour Python ?

Cela s’explique largement par des facteurs techniques, que j’expliquerai, qui font à la fois que le packaging Python est intrinsèquement plus compliqué, et qu’on lui demande beaucoup plus. En vérité, dans ces outils, on trouve des projets qui ont des cas d’utilisation complètement différents et ne s’adressent pas au même public (comme pip et repairwheel). Le hic, c’est qu’il y a, aussi, beaucoup de projets dont les fonctionnalités se recouvrent partiellement, voire totalement, comme entre pip et conda, entre venv et virtualenv, entre hatch et poetry, entre pyinstaller et briefcase, etc. Ces projets sont en concurrence et ont chacun leurs adeptes religieux et leurs détracteurs, à la manière des vieilles querelles Vim/Emacs et compagnie.

Cette dépêche est la première d’une série de quatre, qui ont pour but de décortiquer comment tout cela fonctionne, de retracer comment on en est arrivés là, et de parler des perspectives actuelles :

L’histoire du packaging Python
Tour de l’écosystème actuel
Le casse-tête du code compilé
La structure de la communauté en question

Les outils historiques : distutils et setuptools

Guido van Rossum a créé le langage Python en 1989. Rappelons qu’à l’époque, le World Wide Web n’existait pas encore, ni d’ailleurs le noyau Linux, les deux ayant été créés en 1991. D’après Wikipédia (source), le premier logiciel comparable aux gestionnaires de paquets actuels a été CPAN — destiné au langage Perl — qui ne date que de 1995. Python a donc grandi en même temps que l’idée des paquets, des gestionnaires de paquets et des dépôts sur Internet prenait racine.

C’est en 1998 (source) que le module distutils est né pour répondre au même besoin que CPAN pour Perl, dans le monde Python encore balbutiant. Ce module servait à compiler et installer des paquets, y compris des paquets écrits en C. Historiquement, il permettait aussi de générer des paquets au format RPM de Red Hat, et d’autres formats pour des machines de l’époque comme Solaris et HP-UX (source).

distutils faisait partie de la bibliothèque standard du langage. Il était configuré avec un fichier écrit en Python, nommé conventionnellement setup.py, qui prenait généralement cette forme :

from distutils.core import setup

setup(name='nom-paquet',
      version='x.y.z',
      ...)

On pouvait alors exécuter le setup.py comme un script, en lui passant le nom d’une commande :

$ python setup.py install # installe le paquet
$ python setup.py bdist_rpm # génère un RPM

Le téléchargement de paquets depuis un dépôt partagé ou la résolution des dépendances n’ont jamais fait partie des fonctions de distutils. De façon peut-être plus surprenante, distutils n’offre pas de moyen simple ou fiable pour désinstaller un paquet.

Le projet setuptools est arrivé en 2004 (source) pour pallier les limitations de distutils. Contrairement à distutils, setuptools a toujours été développé en dehors de la bibliothèque standard. Cependant, il était fortement couplé à distutils, le modifiant par des sous-classes… et par une bonne dose monkey-patching (source).

Lesdites limitations ont également conduit à un fork de distutils, nommé distutils2, démarré en 2010. Parmi les raisons citées par son initiateur figure le désir de faire évoluer distutils à un rythme plus soutenu que ce qui était raisonnable pour un module de la bibliothèque standard, surtout un module largement utilisé au travers de setuptools et son monkey-patching (source). Mais distutils2 a cessé d’être développé en 2012 (source).

De même, entre 2011 et 2013 (source), il a existé un fork de setuptools appelé distribute. Ses changements ont fini par être fusionnés dans setuptools.

Pour finir, distutils a été supprimé de la bibliothèque standard dans la version 3.12 de Python, sortie en octobre 2023, au profit de setuptools. Mais cela ne signifie pas que distutils n’est plus utilisé du tout : setuptools continue d’en contenir une copie qui peut être utilisée (bien que ce ne soit pas recommandé).

Il est aussi à noter que NumPy, la bibliothèque Python quasi universelle de calcul scientifique, maintient elle aussi son propre fork de distutils, numpy.distutils, qui est en train d’être remplacé (source). Cela montre à quel point le code de distutils s’est révélé à la fois essentiel, omniprésent à travers divers avatars ou forks, et difficile à faire évoluer.

La montée en puissance de `pip` et PyPI

Avec le développement d’Internet et la croissance de la communauté Python, il devenait nécessaire d’avoir un registre centralisé où pouvaient être déposés et téléchargés les paquets. C’est dans ce but qu’a été créé PyPI, le Python Package Index, en 2002 (source). (Ne pas confondre PyPI avec PyPy, une implémentation alternative de Python. PyPy se prononce « paille paille » alors que PyPI se prononce « paille pie aïe »).

distutils pouvait installer un paquet une fois le code source téléchargé, mais pas installer le paquet depuis PyPI directement, en résolvant les dépendances. Le premier outil à en être capable a été setuptools avec la commande easy_install (source), apparue en 2004.

Puis est arrivé pip en 2008. Entre autres, pip était capable, contrairement à tout ce qui existait jusque là, de désinstaller un paquet ! En quelques années, easy_install est devenu obsolète et pip s’est imposé comme l’outil d’installation standard. En 2013, la PEP 453 a ajouté à la bibliothèque standard un module ensurepip, qui bootstrape pip en une simple commande : python -m ensurepip. De cette manière, pip a pu continuer d’être développé indépendamment de Python tout en bénéficiant d’une installation facile (puisqu’on ne peut évidemment pas installer pip avec pip) et d’une reconnaissance officielle.

L’introduction du format « wheel »

Sans rentrer trop dans les détails à ce stade, le format principal pour distribuer un paquet jusqu’en 2012 était le code source dans une archive .tar.gz. Pour installer un paquet, pip devait décompresser l’archive et exécuter le script setup.py, utilisant setuptools. Bien sûr, cette exécution de code arbitraire posait un problème de fiabilité, car il était critique de contrôler l’environnement, par exemple la version de setuptools, au moment d’exécuter le setup.py.

setuptools avait bien un format de distribution précompilé, le format egg (le nom est une référence aux Monty Python). Un paquet en .egg pouvait être installé sans exécuter de setup.py. Malheureusement, ce format était mal standardisé et spécifique à setuptools. Il était conçu comme un format importable, c’est à dire que l’interpréteur pouvait directement lire l’archive (sans qu’elle soit décompressée) et exécuter le code dedans. C’était essentiellement une façon de regrouper tout le code en un seul fichier, mais il n’y avait pas vraiment d’intention de distribuer les .egg.

La PEP 427 a défini le format wheel pour que les paquets puissent être distribués sous forme précompilée sur PyPI, évitant l’exécution du setup.py durant l’installation.

Parmi les innovations, les fichiers wheels sont nommés d’après une convention qui indique avec quelle plateforme ils sont compatibles. Ceci a grandement facilité la distribution de modules Python codés en C ou C++. Jusqu’ici, ils étaient toujours compilés sur la machine de l’utilisateur, durant l’exécution du setup.py. Avec les wheels, il est devenu possible de distribuer le code déjà compilé, avec un wheel par système d’exploitation et par version de Python (voire moins, mais c’est pour la troisième dépêche).

Les débuts des environnements virtuels

Voici un problème très banal : vous voulez utiliser sur la même machine les projets foo et bar, or foo nécessite numpy version 3.14 alors que bar nécessite numpy version 2.71. Malheureusement, en Python, il n’est pas possible d’installer deux versions du même paquet à la fois dans un même environnement, alors que d’autres langages le permettent. (Plus précisément, il est possible d’installer deux versions en parallèle si elles ont des noms de module différents, le nom de module Python n’étant pas forcément le même que le nom de paquet, cf. Pillow qui s’installe avec pip install pillow mais s’importe avec import PIL. Mais tant que le module Python n’est pas renommé, les deux sont en conflit.)

La solution est alors de se servir d’un environnement virtuel, qui est un espace isolé où on peut installer des paquets indépendamment du reste du système. Cette technique a été développée dans le projet virtualenv, créé par Ian Bicking, qui est aussi l’auteur originel de pip. La première version date de 2007 (source).

Plus tard, en 2012 (source), un module venv a été ajouté à la bibliothèque standard. C’est une version réduite de virtualenv. On peut toutefois regretter que virtualenv soit encore nécessaire dans des cas avancés, ce qui fait que les deux sont utilisés aujourd’hui, même si venv est largement prédominant.

La création de la Python Packaging Authority (PyPA)

La première réaction naturelle en entendant le nom « Python Packaging Authority » est bien sûr de penser qu’à partir de 2012, date de sa création, ce groupe a été l’acteur d’une unification, d’une standardisation, d’une mise en commun des efforts, etc. par contraste avec la multiplication des forks de distutils.

Sauf que… le mot « Authority » était au départ une blague (sérieusement !). La preuve sur l’échange de mails où le nom a été choisi, les alternatives proposées allant de « ianb-ng » à « Ministry of Installation » (référence aux Monty Python), en passant par « Politburo ».

La Python Packaging Authority a démarré comme un groupe informel de successeurs à Ian Bicking (d’où le « ianb ») pour maintenir les outils qu’il avait créés, pip et virtualenv. Elle est un ensemble de projets, reconnus comme importants et maintenus.

Au fil du temps, la partie « Authority » son nom a évolué progressivement de la blague vers une autorité semi-sérieuse. La PyPA d’aujourd’hui développe des standards d’interopérabilité, proposés avec le même processus que les changements au langage Python lui-même, sous forme de PEP (Python Enhancement Proposals), des propositions qui ressemblent aux RFC, JEP et autres SRFI. La PyPA est également une organisation GitHub, sous l’égide de laquelle vivent les dépôts de divers projets liés au packaging, dont la plupart des outils que je mentionne dans cette dépêche, aux exceptions notables de conda, poetry et rye.

La PyPA n’est pas :

Un ensemble cohérent d’outils. Il y a beaucoup d’outils redondants (mais chacun ayant ses adeptes) dans la PyPA. Pour ne donner qu’un exemple, tout ce que peut faire flit, hatch peut le faire aussi.
Une véritable autorité. Elle reste composée de projets indépendants, avec chacun ses mainteneurs. Le fait qu’un standard soit accepté ne garantit pas formellement qu’il sera implémenté. J’ai lu quelque part une allusion à un exemple récent de « transgression » dans setuptools, mais je n’ai pas retrouvé de quel standard il s’agissait. Concrètement, cela ne veut pas dire que les transgressions sont fréquentes, mais plutôt qu’une PEP risque de ne pas être acceptée s’il n’est pas clair que les mainteneurs des outils concernés sont d’accord.

La décision finale sur une PEP est prise par un « délégué », et normalement, cette personne ne fait que formaliser le consensus atteint (même s’il peut y avoir des exceptions).

Il n’y a donc pas de place dans la PyPA actuelle pour des décisions du type de « flit devient officiellement déprécié au profit de hatch ».

Le développement d’un écosystème alternatif, `conda` et Anaconda

Pour compléter la liste de tout ce qui s’est passé en 2012, c’est aussi l’année de la première version de conda.

Cet outil a été créé pour pallier les graves lacunes des outils classiques concernant la distribution de paquets écrits en C ou C++ (Rust était un langage confidentiel à l’époque). Jusque là, on ne pouvait redistribuer que le code source, et il fallait que chaque paquet soit compilé sur la machine où il était installé.

Le format wheel introduit plus haut a commencé à résoudre ce problème, mais toutes ces nouveautés sont concomitantes.

Contrairement à tous les autres outils mentionnés dans cette dépêche, Conda, bien qu’open source, est développé par une entreprise (d’abord appelée Continuum Analytics, devenue Anaconda Inc.). C’est un univers parallèle à l’univers PyPA : un installeur de paquets différent (conda plutôt que pip), un format de paquet différent, un gestionnaire d’environnements virtuel différent (conda plutôt que virtualenv ou venv), une communauté largement séparée. Il est aussi beaucoup plus unifié.

conda adopte un modèle qui se rapproche davantage de celui d’une distribution Linux que de PyPI, en mettant le packaging dans les mains de mainteneurs séparés des auteurs des paquets. Il est possible de publier ses propres paquets indépendamment d’une organisation, mais ce n’est pas le cas le plus fréquent. On pourrait comparer cela à ArchLinux, avec son dépôt principal coordonné auquel s’ajoute un dépôt non coordonné, l’AUR.

Cette organisation permet à conda de faciliter énormément la distribution de modules C ou C++. En pratique, même avec les wheels, cela reste une source infernale de casse-têtes avec les outils PyPA (ce sera l’objet de la troisième dépêche), alors que tout devient beaucoup plus simple avec conda. Voilà son gros point fort et sa raison d’être.

Il faut bien distinguer conda, l’outil, d’Anaconda, qui est une distribution de Python contenant, bien sûr, conda, mais aussi une flopée de paquets scientifiques ultra-populaires comme NumPy, SciPy, matplotlib, etc. Anaconda est très largement utilisée dans le monde scientifique (analyse numérique, data science, intelligence artificielle, etc.). Il existe aussi Miniconda3, qui est une distribution plus minimale avec seulement conda et quelques autres paquets essentiels. Enfin, conda-forge est un projet communautaire (contrairement à Anaconda, développé au sein de l’entreprise Anaconda Inc.) qui distribue des milliers de paquets. On peut, dans une installation d’Anaconda, installer un paquet depuis conda-forge avec conda - c conda-forge (le plus courant), ou bien (moins courant) installer une distribution nommée « Miniforge », qui est un équivalent de Miniconda3 fondé entièrement sur conda-forge.

Les PEP 517 et 518, une petite révolution

S’il y a deux PEP qui ont vraiment changé le packaging, ce sont les PEP 517 et 518.

La PEP 518 constate le problème que le fichier de configuration de setuptools, le setup.py, est écrit en Python. Comme il faut setuptools pour exécuter ce fichier, il n’est pas possible pour lui, par exemple, de spécifier la version de setuptools dont il a besoin. Il n’est pas possible non plus d’avoir des dépendances dans le setup.py autres que setuptools (sauf avec un hack nommé setup_requires proposé par setuptools, qui joue alors un rôle d’installeur de paquets comme pip en plus de son rôle normal… ce pour quoi setuptools n’excellait pas). Elle décrit aussi explicitement comme un problème le fait qu’il n’y ait pas de moyen pour une alternative à setuptools de s’imposer. En effet, le projet setuptools souffrait, et souffre toujours gravement, d’une surcomplication liée à toutes ses fonctionnalités dépréciées.

Pour remédier à cela, la PEP 518 a introduit un nouveau fichier de configuration nommé pyproject.toml. Ce fichier est écrit en TOML, un format de fichier de configuration (comparable au YAML). C’est l’embryon d’un mouvement pour adopter une configuration qui soit déclarative plutôt qu’exécutable. Le TOML avait déjà été adopté par l’outil Cargo de Rust.

Le pyproject.toml contient une table build-system qui déclare quels paquets doivent être installés pour exécuter le setup.py. Elle se présente ainsi :

[build-system]
requires = ["setuptools>=61"]

Cet exemple pourrait être utilisé dans un projet dont le setup.py a besoin de setuptools version 61 au moins.

Mais ce n’est pas tout. La PEP 518 définit aussi une table tool avec des sous-tables arbitraires tool.nom-d-outil, qui permet à des outils arbitraires de lire des options de configuration, qu’ils soient des outils de packaging, des reformateurs de code, des linters, des générateurs de documentation,… pyproject.toml est donc devenu un fichier de configuration universel pour les projets Python. (Anecdote : au départ, il n’était pas prévu pour cela, mais il a commencé à être utilisé comme tel, si bien que la PEP 518 a été modifiée a posteriori pour structurer cela dans une table tool.)

La deuxième étape a été la PEP 517. Elle va plus loin, en standardisant une interface entre deux outils appelés build frontend et build backend. Le build frontend est l’outil appelé par l’utilisateur, par exemple pip, qui a besoin de compiler le paquet pour en faire un wheel installable (ou une sdist, soit une archive du code source avec quelques métadonnées, mais c’est un détail). Le build backend est un outil comme setuptools qui va créer le wheel.

Le rôle du build frontend est assez simple. Pour schématiser, il lit la valeur build-system.requires du pyproject.toml, installe cette liste de dépendances, puis lit la valeur build-system.build-backend, importe le build backend en Python, et appelle la fonction backend.build_wheel().

Voici un exemple de pyproject.toml utilisant les PEP 517 et 518 avec setuptools comme build backend :

[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

Ainsi, il est devenu possible d’écrire et utiliser des build backends complètement différents de setuptools, sans même de fichier setup.py. L’un des premiers build backends alternatifs a été flit, qui cherche à être l’opposé de setuptools : le plus simple possible, avec le moins de configuration possible.

La PEP 517 décrit bien son objectif :

While distutils / setuptools have taken us a long way, they suffer from three serious problems : (a) they’re missing important features like usable build-time dependency declaration, autoconfiguration, and even basic ergonomic niceties like DRY-compliant version number management, and (b) extending them is difficult, so while there do exist various solutions to the above problems, they’re often quirky, fragile, and expensive to maintain, and yet (c) it’s very difficult to use anything else, because distutils/setuptools provide the standard interface for installing packages expected by both users and installation tools like pip.

Previous efforts (e.g. distutils2 or setuptools itself) have attempted to solve problems (a) and/or (b). This proposal aims to solve (c).

The goal of this PEP is get distutils-sig out of the business of being a gatekeeper for Python build systems. If you want to use distutils, great ; if you want to use something else, then that should be easy to do using standardized methods.

La PEP 621, un peu de standardisation

Suite aux PEP 518 et 517, plusieurs build backends alternatifs ont émergé. Bien sûr, tous les build backends avaient des manières différentes de spécifier les métadonnées du projet comme le nom, la version, la description, etc.

La PEP 621 a standardisé cette partie de la configuration, en définissant une nouvelle section du pyproject.toml, la table project. Concrètement, elle peut ressembler à :

[project]
name = "my-project"
version = "0.1"
description = "My project does awesome things."
requires-python = ">=3.8"
authors = [{name = "Me", email = "[email protected]"}]
...

En effet, écrire les métadonnées n’est pas la partie la plus intéressante d’un build backend. Les vraies différences se trouvent, par exemple, dans la prise en charge des extensions C ou C++, ou bien dans des options de configuration plus avancées. La PEP 621 permet de changer plus facilement de build backend en gardant l’essentiel de la configuration de base.

De plus, elle encourage la configuration statique, par opposition au setup.py de setuptools. L’avantage d’une configuration statique est sa fiabilité : aucune question ne se pose sur l’environnement d’exécution du setup.py, sa portabilité, etc.

Pour donner un exemple concret, on apprend dans cette section de la PEP 597 que les développeurs écrivaient souvent dans le setup.py un code qui lit le README avec l’encodage système au lieu de l’UTF-8, ce qui peut rendre le paquet impossible à installer sous Windows. C’est le genre de problèmes systémiques qui sont éliminés par la configuration statique.

Malgré tout, la configuration dynamique reste utile. C’est typiquement le cas pour la valeur de version, qui est avantageusement calculée en consultant le système de contrôle de version (par exemple avec git describe pour Git). Dans ces situations, on peut marquer la valeur comme étant calculée dynamiquement avec

[project]
dynamic = ["version"]

C’est alors au build backend de déterminer la valeur par tout moyen approprié (éventuellement configuré dans la table tool).

L’émergence d’outils tout-en-un alternatifs

Cet historique est très loin d’être exhaustif, et pourtant on sent déjà la prolifération d’outils différents. Face à la confusion qui en résulte, des développeurs ont tenté d’écrire des outils « tout-en-un » qui rassemblent à peu près toutes les fonctionnalités en une seule interface cohérente : installation, build frontend, build backend, gestion des environnements virtuels, installation d’une nouvelle version de Python, mise à jour d’un lock file, etc. Parmi eux, on peut notamment citer poetry, développé depuis 2018 (source), qui se distingue en ne participant pas à la PyPA et en réimplémentant bien plus de choses que d’autres (notamment en ayant son propre résolveur de dépendances distinct de celui de pip). On peut penser aussi à hatch, qui, lui, fait partie de la PyPA et ne fait pas autant de choses, mais s’intègre mieux à l’existant. Et pour mentionner le dernier-né, il y a également rye, qui cherche à modifier la façon dont Python est boostrapé, en utilisant exclusivement des Pythons gérés par lui-même, qui ne viennent pas du système, et en étant écrit lui-même en Rust plutôt qu’en Python.

Conclusion

J’espère que cet historique permet de mieux comprendre pourquoi le packaging est tel qu’il est aujourd’hui.

L’un des facteurs majeurs est l’omniprésence des extensions C, C++ ou maintenant Rust qui doivent être précompilées. C’est la raison essentielle pour laquelle conda et tout son écosystème existent et sont séparés du monde de la PyPA.

Un autre facteur est à chercher dans les problèmes de conception de distutils, un code qui date de l’époque des premiers gestionnaires de paquets et qui n’était pas prêt à accompagner Python pour vingt ans. C’est pour cela qu’il a été forké si souvent, et c’est pour en finir avec l’hégémonie de son fork setuptools que les PEP 518 et 517 ont volontairement ouvert le jeu aux outils alternatifs.

Il faut enfin voir que la PyPA n’a jamais été un groupe unifié autour d’un outil, et qu’il est difficile de changer de modèle social.

Dans la deuxième dépêche, je ferai un tour complet de l’état actuel, en présentant tous les outils et les liens entre eux.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Programme de la PyConFR 23

2023-02-03T10:35:21+01:00

La PyConFR, l'évènement de la communauté francophone du langage de programmation python, aura lieu du 16 au 19 février 2023 à Bordeaux. L'évènement est gratuit mais l'inscription au préalable est obligatoire.

Le programme vient de paraître, le sommaire des conférences, des ateliers et des sprints vous attend dans la suite de cette dépêche.

lien nᵒ 1 : Programme
lien nᵒ 2 : PyConFR

Voici le programme qui vient de paraître : (plus d'infos sur le site)

Conférences (Samedi et Dimanche)

CoWorks, a compositionnal microservices framework using Flask/AWS Lambda and Airflow
Développement VRAIMENT cross-platform avec Python
Portage Python sur Webassembly
Faire du Python professionnel
Python moderne et fonctionnel pour des logiciels robustes
Accessibilité numérique : faire sa part quand on est développeur·euse backend
Devenir incollable sur les callables !
Déployer du backend en 2023
« Fixed bugs » n’est peut-être pas le meilleur message de commit
Apport du langage Python dans un service de recherche hospitalière pour mener des analyses de deep learning
Documentation, logiciel libre et pérennité en arts numériques
Où il est question de gaufre et d’Internet
Garder le contrôle de ses données géolocalisées avant de les partager
Lutter contre le dérèglement climatique avec Django
sphinx-lint : un linter pour ta doc
Continuous performance analysis for Python
NucliaDB, une base de données pour le machine learning et les données non-structurées
Driving down the Memray lane - Profiling your data science work
Trying no GIL on scientific programming
Contribuer à l’open source sur des projets Python… sans coder
Fear the mutants. Love the mutants.
Running real-time machine learning analytics on traces
Python Côte d'Ivoire : Défis et Perspectives
Domain-driven design: what can Python do for you?
Supercharging Jupyter notebooks for effective storytelling
Rejoignez le Fediverse, ajoutez ActivityPub à votre site !
À la découverte de Polars (ou pourquoi vous pourriez quitter Pandas)
Introduction to Sigstore: cryptographic signatures made easier
Python for microcontrollers
Monorepo Python avec environnements de développement reproductibles et CI scalable
The power of AWS Chalice for quick serverless API development in Python
Giving and receiving great feedback through PRs
Uncovering Python’s surprises: a deep dive into gotchas
Python web performance 101: uncovering the root causes
From a Python script to an open-source project
Une bonne quantité de Python peut-elle rendre Firefox moins vulnérable aux supply chain attacks ?
Apprendre Python, c’est pour tout le monde en 2023 ! 💞
Cerveau, Biomarqueurs et Deep Learning
Apprentissage statistique adapté aux données sales avec dirty-cat
Let’s exploit pickle, and skops to the rescue!
Interactive HoloViz Visualization and Dashboards
Cloud infrastructure from Python code: how far could we go?
Traitement de données géographiques avec Rasterio, NumPy, Fiona et Shapely
REX analyse antivirus des fichiers de la plateforme emplois de l’inclusion
J'ai hacké ma chaudière pour avoir un thermostat !
Psycopg, troisième du nom
OCR : apprenez à extraire la substantifique moelle de vos documents scannés
Réinventer le tour du monde en (beaucoup) moins de 80 jours
Django Admin comme framework pour développer des outils internes
Geographic visualization using Streamlit
Transformez vos algorithmes de données/IA en applications web complètes en un rien de temps avec Taipy
Un membre très discret de la famille Jupyter mais pourtant si utile !
Interactive web pages with Django or Flask, without writing JavaScript
Je suis nul·le !
Monitorez vos applications Python (et pas uniquement votre infra)
Nua, un PaaS open source en Python pour l'auto-hébergement de vos applications
GEMSEO : une bibliothèque pour l’optimisation multi-disciplinaire
Save Sheldon: Sarcasm Detection for the Uninitiated!

Ateliers (Samedi et Dimanche)

Le Zen de Python appliqué à la production de jeux vidéo
Initiation à Django à travers la création d'un blog
Faire un module Tryton
Le réseau de neurones qui écrivait des romans
Comment créer des applications web de data science époustouflantes en Python - Tutoriel Taipy
Meme Saheb: using Dank Learning to generate original meme captions
Mettre le web en page(s) : générer un document PDF avec HTML et CSS

Sprints (Jeudi et Vendredi)

Traduction de la doc’ de Python en Français
Sprint sur le projet « Witness Angel »
Complete the work on Modoboa v2
Améliorer l'algorithme de détection de proximité de polygone pour l'étude du potentiel géothermique individuel (transition EnR)
Amélioration de ReservoirPy, un outil simple de Reservoir Computing
Developing community plugins for Argilla: an open-source platform for data-centric NLP
Improve tests for Zou/Kitsu API (Flask)
Sardine : improvisation musicale avec Python 3.10+
Développements de correctifs et tests des modules Ansible
Release d'AnyBlok 2.0.0
Rajout de fonctionnalités et créations de démos complètes et interactives pour Taipy

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Conférence & Atelier PyConFr - du 16 au 19 février 2023 à Bordeaux

2022-11-24T16:23:16+01:00

Quatre journées consacrées au langage Python, la PyConFr revient après deux ans d’absence pour proposer des Sprints, où l’on se retrouve à l’Université de Bordeaux pour coder ensemble le jeudi et vendredi, et des conférences le week-end afin de découvrir les expériences de chacun avec le langage Python.

L’accès est gratuit, ouvert à toutes et tous, cependant l’inscription préalable est nécessaire.

Conférences et ateliers (samedi et dimanche)

Durant le week-end, vous aurez l’occasion de participer à des présentations sur des sujets variés, autour du langage Python, de ses usages, des bonnes pratiques, des retours d’expériences, des partages d’idées…

Codage participatif « Sprints » (jeudi et vendredi)

Les développeurs et développeuses de différents projets open source se rejoignent pour coder ensemble. Chaque personne est la bienvenue pour contribuer, et nous cherchons également à accompagner les débutant·e·s.

Restauration sur place

Des food trucks seront à disposition.

Proposer une conférence ou un atelier

Même un débutant ou une débutante a quelque chose à raconter, alors venez proposer votre conférence sur le site de l’appel à participation.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Des nouvelles de WeasyPrint, ou comment développer du libre à (presque) plein temps

2022-09-22T19:35:27+02:00

WeasyPrint est un générateur de documents qui transforme du HTML/CSS en PDF. C’est écrit en Python, c’est libre (bah oui, sinon on n’en parlerait pas ici), et nous en avions déjà discuté ici il y a quelques années dans un petit article.

Avec le temps (plus de 11 ans depuis le premier commit, que le temps passe vite ma p’tite dame…), le logiciel a gagné une sacrée ribambelle d’utilisateurs avec plus de 750 000 téléchargements par mois. Parmi tous ces gens qui utilisent WeasyPrint, on a forcément rencontré plein de gens avec plein d’idées pour générer plein de drôles de trucs ! Nous avons croisé entre autres des rapports de sécurité informatique 🖥️, des livres de jeu de rôle 🎮️, des tickets 🎫️, des documents scientifiques 🧮️, des factures de sites de vente en ligne 📄️, des compte-rendus biologiques ⚛️, des modes d’emploi de fours 🧑‍🍳️, des lettres officielles 💌️, des étiquettes électroniques 🏷️, des affiches promotionnelles en pharmacies ⚕️, des diplômes universitaires 🎓️…

Forts de ce petit succès, Lucie Anglade et moi (Guillaume Ayoub) avons créé depuis deux ans une structure qui s’appelle CourtBouillon (oui, parce que notre autre passion est la bonne nourriture) dédiée au développement de WeasyPrint et de ses dépendances. Nous avons donc pu passer beaucoup de temps à travailler sur le logiciel et apporter plein de nouveautés, tout en nous posant beaucoup de questions pour assurer un modèle économique viable. Voilà ce que l’on aimerait partager avec vous.

lien nᵒ 1 : Le site de WeasyPrint
lien nᵒ 2 : Le site de CourtBouillon
lien nᵒ 3 : Le dépôt de WeasyPrint
lien nᵒ 4 : Le sondage en cours

Deux ans à toute vitesse

Depuis le début de l’an dernier, nous avons publié 4 versions majeures qui englobent une bonne liste de fonctionnalités dont voici les plus importantes :

les notes de bas de page,
les coupures de blocs après un certain nombre de lignes (pour que le texte ne dépasse pas de la page),
les coupures forcées ou interdites dans les colonnes,
le respect de la norme PDF/A (pour avoir des documents archivables),
les coupures de pages dans les cellules d’un tableau, les blocs flottants et les blocs absolus,
la gestion des polices bitmap (pratique pour faire des étiquettes électroniques parfaites au pixel près),
l’insertion de points de suite (mais si, vous savez ce que c’est, ce sont les petits points entre le nom d’un chapitre et le numéro de page dans une table des matières),
la génération reproductible de fichiers PDF,
le support des principaux sélecteurs CSS de niveau 4 (comme :is(), :where(), :has()),
sans oublier une génération bien plus rapide et des fichiers générés plus petits.

Nous en avons également profité pour créer pydyf, une bibliothèque bas niveau de génération de PDF, histoire d’avoir les mains libres pour ajouter certaines fonctionnalités. C’était une volonté depuis de longues années (pour supporter le format PDF/A par exemple) mais la spécification PDF a nécessité un peu de temps avant d’être apprivoisée 😉️.

Pour parler de tout cela, nous avons écrit une toute nouvelle documentation que nous espérons mieux organisée et plus claire. Nous avons également rédigé une longue série d’articles avec nos copains de Madcats qui ont créé de très jolis documents dont vous pouvez vous inspirer pour créer les vôtres.

En bref, on n’a pas chômé. Mais où a-t-on trouvé tout ce temps ?

Le temps et l’argent

La raison d’être de CourtBouillon est de créer, développer et maintenir des logiciels libres. Et pour cela, il faut avoir du temps, beaucoup de temps, vraiment beaucoup de temps.

Tout le monde veut toujours plein, plein, plein de fonctionnalités, et nous avons un avantage de ce côté-là : CSS en voit fleurir de nombreuses à un rythme soutenu. Comme nous nous appuyons rigoureusement sur ces spécifications, nous avons donc « juste » à les implémenter. Évidemment, à chaque fois qu’une nouvelle propriété est supportée par les navigateurs, les gens se ruent sur nous pour demander pourquoi WeasyPrint ne la supporte toujours pas alors que Chrome et Firefox la gèrent très bien depuis au moins 2 semaines (j’éxagère à peine 😁️). Pour la faire court : ça prend du temps.

Au-delà du code et de ses fonctionnalités, nous passons des jours entiers à trier les tickets, répondre aux questions, tweeter, écrire des articles, corriger des bugs et peaufiner la documentation. Ce travail est peu visible mais il prend bien plus de temps que ce que la plupart des utilisatrices et des utilisateurs imaginent. C’est pourtant un travail de fond nécessaire pour garder nos projets en bonne santé et ne pas crouler rapidement sous les demandes insatisfaites.

Encore au-delà ce travail peu valorisé se cache tout le travail de l’ombre que l’on ne voit pas du tout. Lire des spécifications, que ce soit pour CSS ou PDF, est devenu une seconde nature pour nous, et nous nous sommes habitués au langage étrange que l’on trouve dans ces documents. Certaines rumeurs disent même que nous en rêvons la nuit… Nous devons également faire particulièrement attention à la qualité du code. Nous sommes une toute petite équipe et nous avons, mine de rien, à maintenir un moteur de rendu HTML/CSS… Il est par conséquent très important de s’assurer au quotidien que la dette technique ne s’accumule pas et que l’architecture globale est toujours bien solide, sous peine de se retrouver sous l’eau dans le futur à l’ajout de la moindre fonctionnalité. Au-delà de l’interminable suite de tests (car oui, dans WeasyPrint nous avons plus de lignes de Python pour les tests que pour le code), il est nécessaire de retoucher l’architecture de nos bibliothèques de temps en temps, tout comme nous devons supporter les dernières versions de Python et des diverses dépendances que nous avons.

Pour avoir tout ce temps et en même temps gagner quelque argent pour manger (parce qu’on aime beaucoup ça, je vous le rappelle), nous fournissons divers services à des clients utilisateurs un peu partout dans le monde. Certaines fonctionnalités sont ainsi payées par des entreprises qui ont des besoins spécifiques et sont ensuite ravies d’avoir une belle version toute neuve qui répond parfaitement à leurs besoins. D’autres nous contactent pour avoir de l’aide à la création de documents, nous nous occupons alors de créer du HTML et du CSS aux petits oignons (miam) en accord avec leurs maquettes et leur charte graphique. Nous avons enfin un système de sponsoring et de dons qui ouvre droit à afficher un beau logo sur notre site et à avoir un support prioritaire par mail pour les questions techniques.

Et pour l’instant, ça marche.

Le futur

Même si CourtBouillon est jeune, nous arrivons actuellement à vivre en passant la grande majorité de notre temps de travail sur le libre.

Bien sûr, c’est une situation extrêmement grisante et souvent très épanouissante : qui n’a jamais rêvé de vivre du libre dans ce bon vieux repaire de libristes extrémistes qu’est LinuxFR 😍️ ? Nous avons travaillé notre communication pour toucher des personnes qui partagent nos valeurs, ce qui nous a amenés à rencontrer des gens absolument formidables. Nous avons pu croiser la route de clients disséminés un peu partout dans le monde, nous ouvrir à des problématiques que nous ne connaissions pas et apporter notre aide à des personnes pour lesquelles nous avons beaucoup d’estime et de sympathie…

Il y a bien sûr des contreparties à tout ce bonheur. Au niveau financier, si l’activité actuelle nous permet de nous rémunérer (et c’est déjà appréciable au bout de deux ans), nous sommes loin des standards auxquels nous pourrions postuler en tant qu’ingénieurs en informatique. Nos sponsors et nos clients nous apportent aujourd’hui la majorité de nos revenus, nous sommes donc évidemment soumis aux aléas de la demande avec une alternance de semaines chargées lorsque nous avons beaucoup de clients et des semaines plus creuses où nous pouvons nous atteler au travail invisible. Nous essayons donc au maximum de développer les dons et les sponsors récurrents pour assurer autant que possible la stabilité de notre modèle.

Au niveau des fonctionnalités qui arrivent (parce que c’est ça qui intéresse les gens, hein !), nous avons ouvert un sondage pour mieux connaître les besoins attendus. Celui de l’an dernier nous avait éclairés sur les points à traiter en priorité, nous avons donc pu mettre notre énergie au service des attentes les plus grandes… et bien sûr des clients qui ont gracieusement financé certains de ces développements ! Plusieurs fonctionnalités toutes fraîches sont déjà bien avancées : nous proposerons par exemple dans les prochains mois la possibilité de générer des fichiers PDF plus accessibles (avec le support partiel de PDF/UA) et le support des polices variables.

Et un jour, peut-être, nous pourrons enfin nous lancer à corps perdu dans le support de CSS Grid… si le temps nous le permet 😀️.

En attendant la suite

En attendant la suite des aventures, n’hésitez pas à nous suivre, à jeter un coup d’œil à WeasyPrint si vous ne l’avez jamais essayé, à ouvrir des tickets pour râler si vous rencontrez des problèmes, à nous soutenir si vous aimez ce que l’on fait, et à nous solliciter si vous avez des envies particulières.

Pour celles et ceux qui sont moins intéressés par le côté technique, nous sommes également ouverts pour discuter de gestion de projets libres, du lien à la communauté, de modèles économiques, et de tout ce qui pourrait vous intéresser sur le sujet !

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

PyPI déploie le système 2FA pour les projets critiques écrits en Python

2022-07-16T00:32:11+02:00

PyPI (de l’anglais « Python Package Index ») est le dépôt tiers officiel du langage de programmation Python. Son objectif est de doter la communauté des développeurs Python d’un catalogue complet recensant tous les paquets Python libres.
Google, par l’intermédiaire de l’Open Source Security Foundation (OpenSSF) de la Linux Foundation, s’est attaqué à la menace des paquets malveillants et des attaques de la chaîne d’approvisionnement des logiciels open source. Elle a trouvé plus de 200 paquets JavaScript et Python malveillants en un mois, ce qui pourrait avoir des « conséquences graves » pour les développeurs et les organisations pour lesquelles ils écrivent du code lorsqu’ils les installent.
PyPI déploie le système 2FA (pour double authentification ou authentification à deux facteurs) pour les projets critiques écrits en Python.

lien nᵒ 1 : Annonce implementation 2FA

Ainsi, comme il est possible de le lire sur le compte twitter de PyPI (version nitter fdn.fr ou censors.us), le dépôt va implémenter le 2FA obligatoire pour les projets critiques écrits en Python.

Nous avons commencé à mettre en place une exigence 2FA : bientôt, les responsables de projets critiques devront avoir activé 2FA pour publier, mettre à jour ou modifier ces projets.

Pour s’assurer que ces mainteneurs puissent utiliser des méthodes 2FA fortes, nous distribuons également 4000 clés de sécurité matérielles !

Les 4000 clés de sécurité matérielles sont des clés de sécurité Google Titan. Ces clés seront distribuées aux responsables de projets, avec l’aide de l’équipe de sécurité open source de Google.

Vente autorisées, mais pas partout

La vente des clés Titan n’est autorisée que dans certaines régions géographiques. Ainsi, seuls les développeurs d’Autriche, de Belgique, du Canada, de France, d’Allemagne, d’Italie, du Japon, d’Espagne, de Suisse, du Royaume-Uni et des États-Unis peuvent en recevoir une gratuitement.

Le 2FA en progressions

Il y a déjà un certain nombre de développeurs qui ont activé le 2FA, ainsi, et en toute transparence selon PyPI, le dépôt publie les données sur les comptes 2FA.
Selon PyPI, il y a déjà plus de 28 600 utilisateurs avec 2FA activé, dont près de 27 000 utilisant une application TOTP (par exemple FreeOTP+ sur mobile Android ou via KeepassXC sur un ordinateur).

La PSF (Python Software Foundation) indique qu’elle considère comme critique tout projet figurant dans le top 1 % des téléchargements au cours des six derniers mois. Actuellement, il y a plus de 350 000 projets sur PyPI, ce qui signifie que plus de 3 500 projets sont considérés comme critiques. PyPI calcule ce chiffre quotidiennement, de sorte que le don de Titan devrait permettre de couvrir une grande partie des mainteneurs clés, mais pas tous.
Bien que la plupart des développeurs soient familiers avec le système 2FA, cette exigence pourrait créer des difficultés de connexion.

En effet, si, par exemple, un utilisateur perd sa clé 2FA et qu’il n’a pas configuré d’autres options 2FA, il risque de perdre l’accès à son compte et donc la nécessité de récupérer entièrement un compte, ce qui est lourd et prend du temps à la fois pour les mainteneurs et les administrateurs de PyPI. Il serait donc préférable d’avoir plusieurs méthodes 2FA pour réduire les perturbations potentielles si l’une d’entre elles est perdue.

Conclusion

Est-ce que le 2FA va réellement sécuriser les projets Python ? C’est l’avenir qui le dira. En attendant, il semblerait que PyPI et plus globalement la PSF ait décidé de prendre les choses en main quant à la sécurité des projets Python.

N. D. M. : voir aussi le journal PyPI et les projets critiques sur le même sujet, abordant notamment l'ajout de contraintes supplémentaires (complexité, temps, éventuel coût matériel, vérification régulière du 2FA à effectuer, etc.) pour les passionnés/hobbyistes.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Environnement moderne de travail Python

2022-05-28T19:27:51+02:00

Environnement moderne de travail Python

Si vous développez ou utilisez des programmes s’exécutant au-dessus de l’interpréteur Python, il peut arriver que vous vous retrouviez avec un environnement très dégradé sur votre poste de travail..

Je propose ici de découvrir un ensemble d’outils permettant de configurer des environnements Python qui vous éviteront de polluer votre système ou vos futurs environnements de développement. En effet, entre votre système Linux et les multiples projets de développement sur lequel vous travaillez vous avez souvent besoin d’interpréteur Python dans des versions différentes ou de librairies dans des versions particulières.

Dans ce guide, nous allons voir comment installer un environnement Python répondant aux cas d’usage suivants :

gestion facile de multiple versions de l’interpréteur Python ;
isolation d’applications CLI basées sur Python ;
création d’environnements de développement isolés les uns des autres.

Sommaire

Installation de l’environnement
- Pyenv
- Pip
- Pipx
- Poetry
Mot de la fin

Installation de l’environnement

Nous allons utiliser les outils suivants:

pyenv ;
pip ;
pipx ;
poetry.

Pyenv

Pyenv est un outil qui permet d’installer et gérer facilement vos interpréteurs Python. Il vous permet d’utiliser un interpréteur qui n’est pas celui de votre système.

Les distributions Linux sont souvent livrées avec un Python pré-installé (généralement sous /bin/python) permettant de gérer des programmes nécessaires au bon fonctionnement de votre système. Certains de ces programmes sont critiques et il est donc recommandé de ne pas toucher à l’interpréteur natif de votre système Linux.

Installation de Pyenv

curl https://pyenv.run | bash

Une fois installé, il faut modifier la configuration de votre shell afin qu’il initialise Pyenv à chaque ouverture de terminal.

Ajoutez ces lignes a votre bashrc (ou zshrc):

export PYENV_ROOT="$HOME/.pyenv"
command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"

Ouvrez un nouveau terminal et testez que pyenv :

pyenv
pyenv 2.3.0

Pour installer une version particulière de Python, utilisez la commande pyenv install. Par exemple :

pyenv install 3.9.10

Vous pouvez lister les versions de Python installées

pyenv versions

Pip

Pip est tout simplement un installeur de librairie Python disponible sur https://pypi.org/.

On télécharge l’installeur officiel :

wget https://bootstrap.pypa.io/get-pip.py

On le lance (avec le python3 du système)

sudo python3 get-pip.py

On vérifie que pip3 est bien installé pour notre interpréteur système

pip3 --version
pip 22.1 from /usr/local/lib/python3.10/dist-packages/pip (python 3.10)

Pipx

Pipx permet d’installer des outils CLI dans des environnements isolés et les expose de la même façon que s’ils avaient été installés par pip ou un paquet système.

Très pratique pour éviter les conflits entre plusieurs outils de CLI qui reposent souvent sur des librairies open-source communes mais dans des versions différentes. Il permet aussi d’installer plusieurs versions différentes d’une application CLI.

Installation du paquet venv qui permet de créer des environnements virtuels. Cette librairie est utilisée par pipx pour isoler les installations.

sudo apt install python3-venv

Installation de pipx via pip

sudo pip3 install pipx virtualenv

Pipx expose les applications qu’il installe en ajoutant un lien dans le chemin ~/.local/bin. Il faut donc ajouter ce chemin à votre « PATH ». Dans votre bashrc (ou zshrcè) :

export PATH="$PATH:$HOME/.local/bin/"

On va à présent installer une application basée sur Python. Prenons par exemple Ansible. Ici, nous précisons à pipx d’utiliser l’interpréteur Python installé avec Pyenv précédemment :

pipx install --python /home/nico/.pyenv/versions/3.9.10/bin/python3.9 ansible --include-deps

Ansible est à présent installé dans un environnement virtuel. Les bibliothèques qu’il utilise sont isolées des bibliothèques Python utilisées par le système.

Pour lister les programmes que vous avez installés via pipx :

pipx list

Si le programme que vous avez installé a lui-même besoin d’autres bibliothèques Python pour fonctionner, c’est le cas, par exemple, avec Ansible dont les modules reposent parfois sur des bibliothèques communautaires, vous pouvez les injecter dans l’environnement virtuel. Dans cet exemple, on injecte les bibliothèques pyvmomi, python-ldap, kubernetes et hvac à notre environnement ansible :

pipx inject ansible pyvmomi python-ldap kubernetes hvac

Il est possible également de gérer plusieurs versions d’un même programme et de l’exposer au système avec un suffixe différent. Ainsi, je souhaite installer la dernière version d’Ansible (Ansible 5) tout en gardant la première version installée :

pipx install --suffix -5 --python /home/nico/.pyenv/versions/3.9.10/bin/python3.9 --include-deps ansible

La commande ansible-playbook pour cette version est alors exposée sous ansible-playbook-5.

ansible-playbook-5 --version
ansible-playbook [core 2.12.5]
  config file = None
  configured module search path = ['/home/nico/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/nico/.local/pipx/venvs/ansible/lib/python3.9/site-packages/ansible
  ansible collection location = /home/nico/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/nico/.local/bin//ansible-playbook
  python version = 3.9.10 (main, May 19 2022, 14:16:15) [GCC 11.2.0]
  jinja version = 3.1.2
  libyaml = True

Poetry

Poetry est un gestionnaire de dépendances Python. C’est une sorte de pip++. Il permet d’installer des librairies Python, de s’assurer que l’environnement de développement d’un projet soit isolé et identique pour tous les développeurs, de gérer les conflits d’installation ou encore de publier son paquet Python.

Poetry est un outil CLI écrit en Python, pour l’installation nous pouvons donc utiliser pipx :

pipx install poetry

On vérifie l’installation

poetry --version
Poetry version 1.1.13

Création d’un projet

poetry new poetry-demo

Cette commande effectue 2 choses :

la création d’un répertoire pour le projet avec des fichiers nécessaires à la gestion des dépendances,
la création d’un environnement virtuel pour le projet.

tree poetry-demo

poetry-demo
├── pyproject.toml
├── README.rst
├── poetry_demo
│   └── __init__.py
└── tests
    ├── __init__.py
    └── test_poetry_demo.py

Si l’on veut ajouter une librairie, on va alors se servir de la CLI :

poetry add django

Si l’on souhaite activer l’environnement virtuel du projet, on se place dedans et on appelle la commande shell.

cd poetry-demo
poetry shell

Mot de la fin

Ce tutoriel a été réalisé sur une machine Ubuntu 22.04, mais devrait fonctionner de la même façon sur d’autres distributions. Il existe, bien sur, d’autres façons de gérer ces environnements Python, ceci n’est qu’un exemple qui permet de travailler plus proprement avec Python. Il fonctionne dans un contexte d’administration système avec la gestion des CLI via pipx ou dans un contexte de développement logiciel via l’usage de poetry.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Python pour la fin de l’année 2021

2021-12-25T20:07:41+01:00

En 2019 Oliver commençait une série de dépêches sur le langage Python, série qu’il nous promettait pour la rentrée 2019. Divers aléas ont fait que cette série n’a pu être terminée qu’en juin 2021.

Et, comme cela forme un tout cohérent et qu’il y avait, dès le départ, l’idée de les réunir, l’aboutissement est un, en fait plutôt deux epub qui compilent les dépêches et leurs commentaires parce que la maison ne se refuse rien. Ils sont sur un dépôt github avec les images de couvertures en version svg et png. Idéalement, ils devraient être sur un dépôt plutôt LinuxFr que celui-là.

Vous n’échapperez, évidemment, pas aux petits secrets d’ateliers en fin de dépêche.

lien nᵒ 1 : Python — partie 1 ― Popularité
lien nᵒ 2 : Python — partie 2 ― Python 2
lien nᵒ 3 : Python — partie 3 — Installation de Python et de paquets
lien nᵒ 4 : Python — partie 4 — Py Pyenv
lien nᵒ 5 : Python — partie 5 — Nix (et Guix)
lien nᵒ 6 : Python — partie 6 — Pip et Pipx
lien nᵒ 7 : Python — partie 7 — Environnements virtuels
lien nᵒ 8 : Python — partie 8 — Pipenv
lien nᵒ 9 : Python ― partie 9 ― Formateur de code, analyse statique
lien nᵒ 10 : Python — partie 10 — Entretiens
lien nᵒ 11 : Le fichier epub avec les tableaux d’origine
lien nᵒ 12 : La versions sans tableau plus accessible

Sommaire

Un grand merci pour commencer
Le, ou plutôt les livres électroniques
Dans la fabrique des epub
La question finale

Un grand merci pour commencer

Merci à toutes les personnes qui ont contribué d’une façon ou d’une autre à ces dépêches, ou qui les ont commentées. Cela forme un corpus précieux qui réunit à la fois l’aspect didactique et les expériences.

Un merci tout particulier à :

Oliver qui a commencé la série ;
nokomprendo qui est l’auteur principal du chapitre 5 sur Nix (et Guix) ;
et à Philippe F. qui a terminé la série.

Sans oublier le remotivateur, j’ai nommé : tisaac.

Le, ou plutôt les livres électroniques

Les sujets traités

Vous retrouverez les liens en bas de la page, mais une présentation succincte s’impose. Donc, on commence par la popularité de Python (idéalement j’aurais dû mettre ça à jour, mais bon), pour dire ensuite au revoir à Python 2.

Après ces préliminaires, si je puis dire, on aborde le logiciel sous forme de tutoriels Installation, Py Pyenv, Nix et Giux, Pip et Pipx, les environnements virtuels et Pipenv. La dépêche sur le formateur de code est un retour d’expérience sous forme d’un dialogue à deux voix entre Oliver et Philippe F.

Et enfin, pour conclure en beauté, il y a une série d’entretiens d’utilisateurs du langage. Chacun avec une utilisation, et donc une expérience différente.

Une compilation commentée

On a ainsi la compilation de la série de dépêches plus les commentaires. Les commentaires n’ont, toutefois, pas été tous été repris, pas uniquement par volonté de censure de ma part, mais était-il nécessaire de garder une série de commentaires portant sur une coquille ou complètement hors-sujet ? Ce qui, au final fait très très peu de commentaires en moins (dont des miens soit dit en passant). En revanche, tous les avatars sont partis à la trappe, c’est comme ça¹. J’ai opté pour ajouter un titre « Commentaires », balisé <h2> et d’insérer des filets (que je ne vois pas sur ma liseuse) entre chaque bloc de commentaires pour les différencier. La balise <h2> permet d’arriver directement sur les commentaires.

Par ailleurs, les seules images purement décoratives qui ont été gardées sont celles des entrées de chapitre sur lesquelles est basée la couverture des livres, soit dit en passant.

Il n’y a plus qu’une seule table des matières qui les réunit toutes. J’ai également supprimé des informations redondantes (licence par exemple) ou dépassées (PyConFR de 2019).

Le résultat final est très sûrement perfectible.

Des ? Pourquoi deux fichiers epub ?

Sur ma liseuse, les tableaux de la première dépêche sur la popularité de Python ne rendaient pas du tout et étaient illisibles. J’ai donc fait deux versions, identiques, à cela près qu’il y en a une qui a les tableaux, comme des tableaux et l’autre pour laquelle ils sont en texte, ce qui les transpose dans l’autre sens pour une meilleure lisibilité. Les classements en colonne par année et en ligne pour les langages, c’est bien quand il s’agit d’un tableau. Pour le texte, il vaut mieux avoir une ligne par année.

De cette façon, en plus c’est plus lisible pour les personnes qui ne peuvent pas lire avec leurs yeux. Et ça me paraît extrêmement important.

Où il est question de licence

Les dépêches et les commentaires d’Oliver sont sous licence CC0. Celle par défaut de LinuxFr.org est la licence CC-BY-SA 4 (Attribution ― Partage dans les mêmes conditions). Les epub sont donc sous cette dernière licence, ce qui me paraît un bon compromis.

Dans la fabrique des epub

Les logiciels utilisés

Pour arriver au résultat, j’ai utilisé l’extension pour Firefox Save as eBook dont j’avais touché deux mots ici-même en septembre 2020 et sélectionné le texte (dépêches plus commentaires) pour chaque dépêche. Ça a généré un fichier epub de base mais pas du tout communicable en l’état pour plusieurs raisons outre les éléments déjà donnés :

il y avait la « décoration » LinuxFr : notes, le couple pertinent-inutile, plus les « Discuter », etc. qui n’avaient plus, de mon point de vue, aucun intérêt en dehors du site ;
il fallait ajouter les fichiers images (qui, sinon n’apparaissent pas sur l’epub, ou nécessitent une connexion) ;
plus quelques fautes ici et là (je n’ai pas la prétention d’avoir tout corrigé).

Sans parler des titres des chapitres qui avaient besoin d’être homogénéisés. Et enfin, le fichier généré n’est pas terriblement bien formé apparemment. Il a fallu donc utiliser Sigil (formidable éditeur epub) pour corriger tout ça. Et, évidemment, la postface, les remerciements et la transposition des tableaux en texte ont été faits à partir de LibreOffice. La couverture, quant-à-elle a été concoctée avec Inkscape.

Travailler dans Sigil deux trois astuces

Petit rappel et au cas où : un fichier epub c’est en fait une collection de fichiers texte, ici un par chapitre, images, styles, etc. Le tout dans des dossiers bien spécifiques. Donc, quand on navigue dans Sigil pour modifier un epub, on navigue par fichier texte.

Pour tout dire, j’ai vraiment fait la connaissance de l’éditeur d’epub avec ce travail. Les éléments ci-dessous ne sont là que pour vous donner une idée de comment moi je l’ai utilisé.

Sigil a des boites détachables, comme Inkscape par exemple, je trouve ça très pratique avec deux écrans. Le principal avec le fichier à travailler, le Navigateur et la Prévisualisation dans l’autre ainsi que la boite Insérer un caractère spécial, très utile notamment pour les espaces insécables. En effet, on ne peut pas utiliser le clavier pour ça, à moins d’écrire le code html. Cela dit, avoir des connaissances de base en html est plutôt utile, ça permet de gagner du temps.

Je suggère très fortement de commencer par ouvrir l’Éditeur de métadonnées (menu Outils ou touche F8), en indiquant la langue (par défaut, chez moi c’est l’anglais apparemment), vous pourrez utiliser le module adéquat de correction orthographique (s’il y a du code, ce n’est pas forcément très utile) et en profiter pour donner un titre au document (dc:title), ainsi que d’indiquer le nom de l’auteur (dc:creator, ici j’ai mis « Collectif », c’est mieux qu’inconnu) et, éventuellement, l’éditeur (dc:publisher, ici LinuxFr.org). On peut en ajouter d’autres². Ces métadonnées sont vraiment importantes.

On peut utiliser les fonctions de recherche et de remplacement soit par fichier, soit pour tous les fichiers.

Revoir la table des matières est également indispensable, ne serait-ce que pour lui donner son nom, chez moi c’était « Table of Contents », pour un livre en français, ça ne sonne pas terrible. Noter que, quand on la génère, on peut sélectionner les niveaux retenus.

Pour les images, il faut commencer par les ajouter dans le dossier Images via le Navigateur et ensuite on peut les insérer dans le fichier texte sur lequel on travaille. Et, c’est aussi dans le Navigateur qu’on réorganise l’ordre des chapitres et on met la table des matières où on veut (par défaut elle est en deuxième position, je l’ai déplacé tout à la fin). Curieusement, si Sigil accepte les images au format svg pour les illustrations, il les refuse pour la couverture.

Et, évidemment, le logiciel est capable de corriger un fichier epub pas très correct.

Transposer les tableaux

J’imagine qu’il est possible de faire un script pour ça, mais j’en serais bien incapable. Donc la procédure que j’ai utilisée, plus rapide à faire qu’à décrire :

copie du tableau à partir de la dépêche ;
collage dans Calc puis à nouveau copie de ce tableau dans Calc ;
toujours dans Calc, collage transposé ;
ajout des colonnes supplémentaires là où il faut, pour ici ajouter le rang du langage, les balises (ici <p>et </p> pour chaque ligne mais aussi <b> et </b> pour la mise en relief), rentrer le premier élément d’une colonne (par exemple le numéro avec les fioritures pour la lecture), sélectionner les cellules de la colonne et faire un Ctrl + D pour que tout ça se recopie vers le bas ;
copier et coller sans mise en forme le tableau dans Writer pour le transformer en texte ;
copier le texte obtenu et le coller dans Sigil.

La question finale

Il y en aura d’autres ?

Non !

Sur ce bonne lecture et bonne fin d’année.

Il aurait peut-être été intéressant de les garder, malgré le travail supplémentaire que cela impliquait de les ajouter, si tout le monde avait eu un avatar personnalisé. Ce qui n’est pas le cas. ↩
DC : pour métadonnées du Dublin Core qui traite de la description des ressources informatiques. ↩

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Décès de Fredrik Lundh (Effbot), auteur des bibliothèques PIL et Tkinter

2021-12-16T20:58:20+01:00

Fredrik Lundh était un contributeur Python ayant créé les bibliothèques de traitement d’image PIL et de GUI Tkinter. Il était connu pour avoir mis en ligne le site de tutoriel effbot.org couvrant ces bibliothèques. Son décès a été annoncé le 10 décembre 2021 sur la liste de diffusion des développeurs principaux du langage Python.

lien nᵒ 1 : Tkinter (Wikipedia)
lien nᵒ 2 : PIL (Wikipedia)
lien nᵒ 3 : [email protected]/thread/36Q5QBILL3QIFIA3KHNGFBNJQKXKN7SD/" hreflang="en" href="https://linuxfr.org/redirect/109566">Annonce du décès sur la liste de diffusion Python-Dev
lien nᵒ 4 : effbot.org avant sa maintenance
lien nᵒ 5 : Page de présentation sur wiki.python.org

Fredrik Lundh a été un contributeur influent des débuts du langage Python et a beaucoup participé à la promotion de ce langage à travers l’édition de diverses bibliothèques et par l’aide qu’il apportait sur Usenet comp.lang.python aux débutants aussi bien qu’aux utilisateurs avancés.

Il a cofondé dans les années 90 une des premières startups Python « Secret Labs AB » au sein de laquelle il a développé entre autres, l’IDE PythonWorks. En 2001, il a publié chez O'Reilly « Python Standard Library » dans le but de fournir une documentation testée et précise de tous les modules de la Python Standard Library, avec plus de 300 exemples de scripts annotés utilisant les modules.

[email protected]/message/36Q5QBILL3QIFIA3KHNGFBNJQKXKN7SD/">Guido van Rossum dans son hommage destiné à toute la communauté des développeurs Python termine avec ces mots : « Il va nous manquer ».

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Python 3.10 est disponible

2021-08-04T15:30:26+02:00

Python 3.10 (rc1) est sorti le 2 août 2021, après quinze mois de développement (dont cinq à cheval sur les bêta et les rc de Python 3.9). Il reste deux mois avec des candidats (RC) avant la sortie définitive, prévue le 4 octobre 2021.

Voyons ce que cette version apporte comme nouveautés…

lien nᵒ 1 : Notes de version 3.10.0rc1
lien nᵒ 2 : Notes de version 3.10.0

Sommaire

PEP 623 − Préparation de la suppression de wstr dans PyUnicodeObject
PEP 604 − Écrire les unions de types plus facilement
PEP 612 − Amélioration du typage pour les décorateurs
PEP 626 − Numéro de ligne précis pour les débugueurs et autres outils
PEP 618 − Ajout d’une vérification optionnelle des longueurs dans zip
Bug 12782 − Groupement des gestionnaires de contexte avec des parenthèses
PEP 632 − Dépréciation du module distutils
PEP 613 − Alias de types explicites
PEP 634/635/636 − Ajout du mot-clé match pour faire du filtrage par motif.
PEP 644 − OpenSSL 1.1.1 ou plus récent est maintenant requis
PEP 624 − Retrait des API d’encodage Py_UNICODE
PEP 597 − Ajout d’un EncodingWarning optionnel
Bug 38605 − Évaluation retardée des annotations (non-inclus dans Python 3.10)
Pour tester
- Utilisation d’un conteneur
- Compilation depuis les sources
Compatibilité

Cette version comporte pas moins de onze nouveautés et une correction par rapport à la version 3.9 sortie le 5 octobre 2020.
Une correction (changement de défaut) n’a finalement pas été incluse dans cette version.

PEP 623 − Préparation de la suppression de `wstr` dans `PyUnicodeObject`

PEP 623 : il n’y a plus aucune raison de garder la compatibilité avec les chaînes à larges caractères (wide string) dans l’implémentation Unicode de Python.

En effet, wstr et wstr_length avaient été introduits pour une meilleure compatibilité des extensions en C pour Python 2 et 3. Vu que Python 2 est maintenant déclaré mort, il n’y a plus besoin de garder ces API qui seront marquées comme dépréciées à partir de Python 3.10 et supprimées en version 3.12.

Le gain en mémoire est de 8 octets par chaîne de caractères, ce qui n’est pas rien.

PEP 604 − Écrire les unions de types plus facilement

PEP 604 : avant, pour écrire l’union de type en Python, il fallait écrire Union[X, Y].

Il fallait donc importer Union de typing pour pouvoir faire une union, et la lecture n’était pas limpide.

Cette proposition permet d’écrire X | Y, ce qui apporte à la fois les avantages d’une lecture simplifiée, et d’un import de moins.

Cela parait simple au niveau grammaire, mais pour que ça fonctionne au niveau du code, il a fallu ajouter la méthode magique __or__ à la super-classe/l’objet type.

Du coup on gagne aussi dans d’autres domaines, comme les écritures suivantes :

isinstance(5, int | str)
isinstance(None, int | None)

PEP 612 − Amélioration du typage pour les décorateurs

PEP 612 : la PEP 484 et la PEP 544 permettent de décrire des fonctions de retour d’appel (callback).

Sur un décorateur, en définissant un TypeVar, on peut définir une valeur de retour pour le décorateur qui correspond au type de la fonction décorée. Il n’était toutefois pas possible de faire la même chose avec les arguments.

La PEP 612 comble ce manque en introduisant ParamSpec qui englobe la définition d’arguments. ParamSpec contient notamment les attributs args et kwargs qui correspondent respectivement aux types des arguments positionnels et nommés.

Exemple :

from typing import Awaitable, Callable, ParamSpec, TypeVar

P = ParamSpec("P")
R = TypeVar("R")

def add_logging(f: Callable[P, R]) -> Callable[P, Awaitable[R]]:
  async def inner(*args: P.args, **kwargs: P.kwargs) -> R:
    await log_to_database()
    return f(*args, **kwargs)
  return inner

@add_logging
def takes_int_str(x: int, y: str) -> int:
  return x + 7

await takes_int_str(1, "A")  # accepté
await takes_int_str("B", 2)  # rejeté par le vérifieur de type

PEP 626 − Numéro de ligne précis pour les débugueurs et autres outils

PEP 626 : les attributs f_lineno et co_lnotab d’une pile (frame) d’exécution ne donnent pas toujours le bon numéro de ligne du code source dans certains cas.

La correction consiste à marquer des bytecodes comme virtuels et n’ayant pas de ligne dans le code source.

Afin de garantir la compatibilité avec les outils existants, rien n’est modifié sur co_lnotab mais une nouvelle méthode co_lines() est disponible. co_lnotab sera donc toujours disponible mais généré à la demande.

PEP 618 − Ajout d’une vérification optionnelle des longueurs dans `zip`

PEP 618 : sécurisation optionnelle de l’utilisation de la fonction zip.

La fonction zip permet d’itérer sur plusieurs séquences ou générateurs à la fois et de retourner un tuple de valeurs des différents itérateurs.

Si un itérateur n’a plus d’élément à itérer, zip s’arrête sans erreur, même si un autre itérateur a encore des éléments à itérer. Cette PEP rajoute une option pour déclencher une erreur dans une telle situation.

Exemple :

>>> list(zip(range(3), range(2, 5)))
[(0, 2), (1, 3), (2, 4)]
>>> list(zip(range(3), range(2, 4)))
[(0, 2), (1, 3)]
>>> list(zip(range(3), range(2, 4), strict=True))
ValueError: zip() argument 2 is shorter than argument 1

Bug 12782 − Groupement des gestionnaires de contexte avec des parenthèses

BPO 12782 : grouper des gestionnaires de contexte avec des parenthèses est désormais officiellement autorisé.

Contrairement aux autres mots-clés, il n’était pas possible d’utiliser les parenthèses avec with:

with (open("a_really_long_foo") as foo,
      open("a_really_long_bar") as bar):
    pass

Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "demo.py", line 19
    with (open("a_really_long_foo") as foo,
                                    ^
SyntaxError: invalid syntax

Il fallait s’en remettre aux \ pour sauter des lignes:

with open("a_really_long_foo") as foo, \
      open("a_really_long_bar") as bar:
    pass

Désormais, la première syntaxe sera valide, comme on peut légitimement s’y attendre, renforçant la cohérence du langage. Cette fonctionnalité a pu être introduite facilement grâce au nouveau PEG parser ajouté dans Python 3.9.

PEP 632 − Dépréciation du module `distutils`

PEP 632 : le module distutils est déprécié car une version est maintenant intégrée dans setuptools qui ne dépend plus de la librairie standard de Python.

distutils n’était pas très documenté ni maintenu dans la librairie standard de toutes façons.

Ça laisse également le champ libre pour la PEP 517 qui veut construire un système de construction indépendant.

PEP 613 − Alias de types explicites

PEP 613 : ajout d’un type « Alias de type » pour permettre de définir les alias de type de manière explicite.

Jusqu’à présent la différence entre une affectation d’une valeur à une variable et d’une définition d’alias de type était assez ténue et ambiguë.

Exemple d’ambiguïté :

MonType = "ClassName"
def foo() -> MonType:
    pass

Ici, il est difficile de savoir si MonType est une variable dont la valeur est une string ClassName ou si c’est un alias de type sur la classe ClassName qui sera définie plus tard. Les vérifieurs de types se trompant souvent et rapportant de fausses erreurs, il a fallu se rendre à l’évidence : cette notation n’est pas assez explicite.

Cette PEP, propose :

MonType: TypeAlias = "ClassName"
def foo() -> MonType:
    pass

Là, plus d’ambiguïté.

PEP 634/635/636 − Ajout du mot-clé `match` pour faire du filtrage par motif.

PEP 634, PEP 635 et  PEP 636: filtrage par motif grâce au mot-clé match.

Cette PEP a été divisée en trois parties : définition, justification, tutoriel. La lecture du tutoriel est un bon point de départ pour lire ces PEP.

L’amélioration vient du constat suivant : il est souvent nécessaire de faire une suite de if … elif … elif … else qui concerne un même élément. Ces tests peuvent porter sur du duck-typing (est-ce que cet objet couac comme un canard), sur de l’héritage, sur une liste de valeurs (comparaison sur des strings ou des numériques par exemple), sur une taille de séquence (liste, tuple) et d’autres tests.

Cela fonctionne très bien avec des if mais c’est pas toujours super lisible parfois, et comme ce schéma se répète souvent dans les projets Python, il a été décidé d’aider les développeurs (ceux qui écrivent mais surtout ceux qui lisent) avec l’aide des mots-clés match et case (et copier ce qu’on peut trouver sur d’autres langages)

Les mots-clés match et case ne sont pas des termes réservés, on peut donc toujours les utiliser dans des noms de variables, le parseur faisant la différence de construction. Le code pré-python-3.10 reste donc compatible. Python parle de soft keywords.

Le concept de filtrage par motifs s’explique par le fait que la variable (ou l’expression) à tester est comparée à des motifs et permet de sélectionner exclusivement un bloc de code.

Exemple de code gérant un jeu de rôle par entrée textuelle :

command = input("Que voulez-vous faire ? ")
match command.split():
    case ["quitter"]:
        print("Au revoir !")
        quit_game()
    case ["regarder"] | ["scruter"]:
        current_room.describe()
    case ["aller", "côté", ("Nord" | "Sud" | "Est" | "Ouest") as direction] | [("Nord" | "Sud" | "Est" | "Ouest") as direction] if direction in current_room.exits:
        current_room = current_room.neighbor(direction)
    case [("Nord" | "Sud" | "Est" | "Ouest")] | [_]:
        print("Désolé, il n’y a pas de sortie dans cette direction")
    case ["prendre", obj] | ["ramasser", obj] | ["mettre", obj, "dans", "le", "sac"]:
        character.get(obj, current_room)
    case ["lâcher", *objects]:
        for obj in objects:
            character.drop(obj, current_room)
    case _:
        print(f"Désolé, je ne comprends pas ce que veut dire {command!r}")

On peut comprendre le code en un clin d’œil, ce qui ne serait pas forcément le cas avec des if. De plus on peut voir que la syntaxe de déconstruction permet de valider le format attendu, mais également de récupérer des variables liées (bind en anglais). Si des alternatives sont présentes dans le motif, alors chaque alternative doit lier les mêmes variables. L’utilisation de l’expression if condition après le motif permet de garder le bloc sous une condition spéciale, supplémentaire au motif, et évaluée après la correspondance au motif et après les bind.

Enfin l’utilisation de la variable _ permet de définir des cas par défaut. En effet il est de convention en Python d’utiliser _ pour définir une variable que l’on ne va pas utiliser et qui sert de variable fictive (placeholder).

On peut également utiliser la notation avec une ou deux étoiles pour récupérer une liste d’éléments ou un dictionnaire. Notations *lst ou **d comme on peut le faire dans la syntaxe de déconstruction classique.

Les comparaisons de motifs peuvent se faire en profondeur. L’égalité (==) est utilisée pour comparer les objets et littéraux, sauf pour True, False et None ou c’est l’identité (is).

Il est également possible de comparer avec des classes en utilisant cette syntaxe :

match event.get():
    case Click(position=(x, y)):
        handle_click_at(x, y)
    case KeyPress(key_name="Q") | Quit():
        game.quit()
    case KeyPress(key_name="up arrow"):
        game.go_north()
    ...
    case KeyPress():
        pass # Ignore other keystrokes
    case other_event:
        raise ValueError(f"Unrecognized event: {other_event}")

Ici on va vérifier le type de retour de event.get() avec les types d’objets indiqués dans les différents case. Attention, même si la syntaxe donne l’impression que des objets sont créés (Click(position=(x, y)), Quit()) il n’en est rien.

Ce qui est donné entre parenthèses restreint le motif à une classe qui hérite de la classe indiquée (exemple Click) et qui contient un attribut position dont le motif correspond à un tuple de deux éléments qui seront liés aux variables x et y.

On peut bien évidemment mixer tous ces types de motifs. L’expressivité créée par cette PEP est énorme et des tests menés par Python montre une meilleure lisibilité sur une grosse partie du code source des modules Python et une réduction du nombre de lignes.

Bref, après des années de demande pour avoir un switch/case en Python, en voilà un sous stéroïdes !

PEP 644 − OpenSSL 1.1.1 ou plus récent est maintenant requis

PEP 644 : OpenSSL (version 1.1.1 ou supérieure) sera nécessaire pour Python 3.10.

Il existe trop de différences entre les versions d’openssl (1.0.2, 1.1.0 et 1.1.1) pour que les deux experts qui gèrent ça chez Python puissent fournir un code compatible avec toutes. C’est la même raison pour libressl qui ne sera plus pris en charge à partir de Python 3.10.

Pour résumer, seule l’API d’openssl 1.1.1 est prise en charge.

Ça ne devrait pas trop impacter les distributions selon la PEP 644 car openssl 1.1.1 est la version par défaut sur la plupart des plateformes et distributions (Linux et BSD). Les rares distributions qui utilisent LibreSSL devraient probablement avoir migré sur OpenSSL d’ici à ce que Python 3.10 sorte.

PEP 624 − Retrait des API d’encodage `Py_UNICODE`

PEP 624 : planification du retrait des API inutilisée PyUnicode_* pour Python 3.11.

Cette PEP sort donc pour Python 3.10 mais n’aura d’effet que pour la version suivante.

PEP 597 − Ajout d’un `EncodingWarning` optionnel

PEP 597 : ajout d’un EncodingWarning optionnel lors de l’ouverture d’un fichier en mode texte.

En effet sous Linux, BSD et MacOS, l’encodage par défaut des fichiers est très généralement UTF-8. Mais ce n’est pas toujours le cas. Quand on ouvre un fichier en mode texte, c’est l’encodage par défaut du système qui est utilisé (qui peut être surchargé avec la variable d’environnement LANG par exemple).

On peut préciser/forcer l’encodage à utiliser pour les caractères/octets en le spécifiant dans un paramètre encoding. Celui-ci existe depuis fort longtemps, mais force est de constater que la plupart des bibliothèques et codes en python ne le précisent pas.

Cette PEP vise à ajouter un avertissement EncodingWarning quand le paramètre encoding n’a pas été précisé pour un fichier ouvert en mode texte.

Afin d’activer cet avertissement, il faut invoquer Python avec les paramètres -X warn_default_encoding ou bien définir la variable d’environnement PYTHONWARNDEFAULTENCODING à 1.

Illustration de code correct (ne générant pas le warning) :

with open(`my_file.txt`, encoding='utf-8') as f:
    content = f.read()

Bug 38605 − Évaluation retardée des annotations (non-inclus dans Python 3.10)

BPO 38605 : l’évaluation retardée des annotations, qui est disponible depuis Python 3.7 en utilisant une ligne from __future__ import annotations est maintenant disponible par défaut.

Pour rappel, la PEP 563 permet d’évaluer les annotations au lancement et pas simplement lors de la définition/compilation.

Les annotations sont présentes dans __annotations__. On peut les lire avec get_type_hints de typing. Les annotations sont toujours présentées comme du code python valide.

On peut par exemple les lire à l’exécution comme suit :

>>> import typing
>>> def x(a: 'int'): pass
>>> typing.get_type_hints(x)
{'a': ForwardRef('int')}

** /!\ Cette modification a été repoussée à Python 3.11 en raison de certaines incompatibilités **
[email protected]/thread/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/">Plus d’info

Pour tester

Pas envie d’attendre que ce soit disponible dans votre distribution ? Deux options : utiliser un conteneur ou compiler depuis les sources.

Utilisation d’un conteneur

$ docker run --rm -it python:3.10.0rc1-slim

Compilation depuis les sources

En fait c’est pas si compliqué du tout et ça se compile assez vite, donc c’est une option viable, même pour tester.

Dépendances nécessaires : expat, bzip2, gdbm, openssl, libffi, zlib, tk, sqlite, bluez-libs, mpdecimal
Sous Debian/Ubuntu c’est : expat libbz2-dev liblzma-dev libgdbm-dev libdb5.3-dev libdb5.3++-dev libssl-dev libffi-dev zlib1g-dev tk-dev libsqlite3-dev libbluetooth-dev libncurses-dev libreadline-dev

Ensuite il suffit de récupérer le tarball et de lancer la compilation et l’installation (c’est tiré du paquet AUR sur ArchLinux) :

$ wget 'https://www.python.org/ftp/python/3.10.0/Python-3.10.0rc1.tar.xz'
$ tar xf Python-3.10.0rc1.tar.xz
$ cd Python-3.10.0rc1
$ rm -rf Modules/{expat,zlib} Modules/_ctypes/{darwin,libffi}*
$ # Vous pouvez vous passer de enable-optimizations pour compiler plus vite si vous voulez
$ ./configure --prefix=/usr \
              --enable-shared \
              --with-computed-gotos \
              --enable-ipv6 \
              --with-system-expat \
              --enable-loadable-sqlite-extensions \
              --without-ensurepip \
              --enable-optimizations
$ make
$ mkdir -p pkg
$ sudo make DESTDIR="$PWD/pkg" altinstall maninstall
$ sudo rm -f "$PWD/pkg/usr/lib/libpython3.so" "$PWD/pkg/usr/share/man/man1/python3.1"
$ sudo ln -sf ../../libpython3.10m.so \
    "$PWD/pkg/usr/lib/python3.10/config-3.10-$(uname -m)-linux-gnu/libpython3.10m.so"
$ sudo ln -sf python3.10m-config "$PWD/pkg/usr/bin/python3.10-config"
$ sudo install -dm755 "$PWD/pkg/usr/lib/python3.10/Tools"/{i18n,scripts}
$ sudo install -m755 Tools/i18n/{msgfmt,pygettext}.py "$PWD/pkg/usr/lib/python3.10/Tools/i18n/"
$ sudo install -m755 Tools/scripts/{README,*py} "$PWD/pkg/usr/lib/python3.10/Tools/scripts/"
$ sudo cp -a pkg/* /
$ python3.10

Compatibilité

Python 3.10 est grandement compatible avec les versions précédentes. Ça devrait donc être très facile de passer à cette version pour votre projet.
Il y a toutefois quelques limitations temporaires :

Certains paquets Python compilés ne fournissent par encore de wheel (paquets binaires) pour Python 3.10 et donc l’installation d’un tel paquet va demander une compilation.
Le paquet numpy, ainsi que pandas qui en dépend, fait partie de cette catégorie. La compilation peut s’avérer compliquée si vous êtes sur une distribution qui fait du morcelage de paquets (-dev, -doc, …). Il vous faudra alors installer une myriade de paquets systèmes (en plus du compilateur) pour pouvoir installer votre paquet python compilé.
Donc changer uniquement votre environnement en Python 3.10 n’est pas forcément suffisant. Ceci est bien sûr temporaire et les auteurs de ces bibliothèques fourniront pour sûr des wheels prochainement.
Certains paquets Python n’ont pas pensé que la version mineure de Python pouvait tenir sur deux chiffres au lieu d’un.
Je pense notamment à uwsgi. Mais c’est corrigé sur la branche principale et une version va voir le jour.

Ce ne sont que de petites contraintes qui vont se corriger d’ici que la finale sorte début octobre, mais en attendant, si vous voulez tester/anticiper, vous savez à quoi vous attendre.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Python — partie 9 ― formateur de code, analyse statique

2021-06-09T09:49:40+02:00

Cette dépêche est la suite d’une série sur Python initiée en septembre 2019. Après un sommeil cryogénique d’un an et demi, on repart en forme avec d’autres contenus Python à vous proposer : actualité, bonnes pratiques, astuces, témoignages… Elle a été rédigée principalement à deux voix, Oliver et Philippe, qui vous font part de leur expérience sur les fonctions.

Cette dixième partie présente les formateurs de code bien pratiques et les analyseurs de code. 🐍 🐍 🐍

Pour rappel, les autres dépêches déjà publiées :

Python — Popularité
Python — Python 2
Python — Installation de Python et de paquets
Python — Py Pyenv
Python — Nix (et Guix)
Python — Pip et Pipx
Python — environnements virtuels
Python — Pipenv
Python — Entretiens

lien nᵒ 1 : Python — partie 1 ― Popularité
lien nᵒ 2 : Python — partie 2 ― Python 2
lien nᵒ 3 : Python — partie 3 — Installation de Python et de paquets
lien nᵒ 4 : Python — partie 4 — Py Pyenv
lien nᵒ 5 : Python — partie 6 — Pip et Pipx
lien nᵒ 6 : Python — partie 7 — Environnements virtuels
lien nᵒ 7 : Python— partie 8 — Pipenv
lien nᵒ 8 : Python — partie 10 — Entretiens

Sommaire

Formateurs de code source

Les formateurs de code source ne dépendent pas des modules utilisés par les projets. Donc nous pouvons les installer avec pip :

python3 -m pip install --progress-bar emoji --user --upgrade black
python3 -m pip install --progress-bar emoji --user --upgrade yapf
python3 -m pip install --progress-bar emoji --user --upgrade autopep8
python3 -m pip install --progress-bar emoji --user --upgrade docformatter

Par la suite, ils seront illustrés avec l’exemple suivant :

$ cat > bateau.py
capitaine = { 'age':   42,       # univers ?
              'nom':  'Grant',
              'pays': 'Royaume-Uni',
            }
navire    = { 'nom':       'Britannia',
              'longueur':   127,# metres
              'tonnage':    5860,
              'lancement': "16 mars 1953"
            }

mission  =  { "commandant" : capitaine , 'bateau' : navire , }
f  =  lambda x:   True if x%9 == 0   else False

`black`

Le projet black est très récent, son premier commit date de mars 2018. Et pourtant ce formateur de code Python bénéficie d’un succès énorme avec plus de 20 000 étoiles sur GitHub (et une centaine de contributeurs).

Son succès est lié à la quasi-absence de configuration et fonctionne dans le même esprit que gofmt, c’est-à-dire que les développeurs n’ont plus à discuter des règles de codage. C’est toujours black qui a raison et on ne perd plus de temps à négocier les règles, à les rediscuter en revue de code… On se concentre sur son travail : coder sans se prendre la tête à bien indenter. De toutes façons, black va changer l’indentation avec ses propres règles de codage non-négociables : uncompromising Python code formater.

Les deux seuls paramètres sur lesquels on peut encore chipoter :

--line-length 88
--skip-string-normalization
(si présent ne remplace pas 'texte' par "texte")

Exemple :

$ black .
reformatted bateau.py
All done! ✨ 🍰 ✨
1 file reformatted.

$ cat bateau.py
capitaine = {"age": 42, "nom": "Grant", "pays": "Royaume-Uni"}  # univers ?
navire = {
    "nom": "Britannia",
    "longueur": 127,  # metres
    "tonnage": 5860,
    "lancement": "16 mars 1953",
}

mission = {"commandant": capitaine, "bateau": navire}
f = lambda x: True if x % 9 == 0 else False

Une discussion a été ouverte sur le fait de passer le code de la lib standard de Python par black, mais, pour l’instant, il y a pas mal d’éléments qui font que ça n’aura pas lieu. Un des arguments principaux est de ne pas surcharger le nombre d’outils nécessaires pour une contribution à Python.

`blue`

Le projet blue est un dérivé de black avec quelques ajustements sur les points qui sont les plus controversés.

Les différences avec black:

utilisation des simples guillemets pour les chaînes de caractère (en dehors de docstring) ;
longueur de ligne à 79 caractères ;
configuration via plusieurs mécanismes possibles, pyproject.toml, setup.cfg, tox.ini, et .blue.

Il s’utilise à l’identique de black et est disponible sous pypi.org

`yapf`

Le projet Yet Another Python Formatter est plus vieux que black (premier commit en mars 2015), a moins d’étoiles (9 700) et le même nombre de contributeurs.

L’innovation de yapf réside dans la réutilisation du puissant clang-format. Les règles de sa configuration sont prises en compte pour calculer le score de tel ou tel reformatage et de boucler ainsi afin d’obtenir le meilleur score.

L’idée est superbe, mais en pratique, on passe trop de temps à essayer de peaufiner la configuration sans trop comprendre quel paramètre influe sur telle indentation. Et comme c’est configurable, une personne va passer du temps pour tenter d’améliorer les choses. Et pire, dans de rares circonstances, yapf peut reformater un code source différemment deux fois de suite ! (avec la même configuration)

En fait, le seul paramètre que nous devrions tester c’est --style avec les valeurs actuelles : pep8 (défaut), google, chromium et facebook.

Le résultat à partir du même fichier d’origine quel que soit le paramètre --style :

$ yapf bateau.py
capitaine = {
    'age': 42,  # univers ?
    'nom': 'Grant',
    'pays': 'Royaume-Uni',
}
navire = {
    'nom': 'Britannia',
    'longueur': 127,  # metres
    'tonnage': 5860,
    'lancement': "16 mars 1953"
}

mission = {
    "commandant": capitaine,
    'bateau': navire,
}

`autopep8`

Le projet autopep8 est encore plus vieux (premier commit en décembre 2010), a encore moins d’étoiles (3 000) et moins de contributeurs (une trentaine).

Ce formateur de code est beaucoup moins agressif que les deux premiers, car il ne reformate pas ce qui est compatible avec les règles PEP8. Cependant quelques corrections sont intéressantes comme le remplacement de f = lambda x: par def f(x):.

Le formateur autopep8 semble avoir --max-line-length comme seule règle de formatage. En fait, sa configuration est différente des deux autres : l’option --ignore permet de désactiver des règles. Les options --aggressive et --experimental sont intéressantes.

Exemple :

$ autopep8 --aggressive --aggressive --aggressive bateau.py
capitaine = {'age': 42,       # univers ?
             'nom': 'Grant',
             'pays': 'Royaume-Uni',
             }
navire = {'nom': 'Britannia',
          'longueur': 127,  # metres
          'tonnage': 5860,
          'lancement': "16 mars 1953"
          }

mission = {"commandant": capitaine, 'bateau': navire, }


def f(x):
    return True if x % 9 == 0 else False

`isort`

Le projet isort a une ambition plus modeste que les précédents formateurs de code. Il se focalise sur les imports et vous propose de les reformater pour vous simplifier la vie. La première version officielle date de 2013 et le projet est toujours assez actif et dispose de 3900 étoiles sous GitHub.

Le README du projet donne un bon exemple de son action.

Avant :

from my_lib import Object

import os

from my_lib import Object3

from my_lib import Object2

import sys

from third_party import lib15, lib1, lib2, lib3, lib4, lib5, lib6, lib7, lib8, lib9, lib10, lib11, lib12, lib13, lib14

import sys

from __future__ import absolute_import

from third_party import lib3

print("Hey")
print("yo")

Après isort :

from __future__ import absolute_import

import os
import sys

from third_party import (lib1, lib2, lib3, lib4, lib5, lib6, lib7, lib8,
                         lib9, lib10, lib11, lib12, lib13, lib14, lib15)

from my_lib import Object, Object2, Object3

print("Hey")
print("yo")

Donc concrètement :

regroupement des imports par groupe, les __future__ en premier, la lib standard en deuxième, les autres lib par la suite ;
regroupement des imports divers d’une bibliothèque sur un seul import ;
tri par ordre alphabétique des imports au sein d’un même groupe ;
formatage sous forme de bloc équilibré pour lib1 à lib15 par exemple ;
on ne touche pas au reste du code.

L’ambition du projet est modeste mais sympathique, et ça fonctionne bien. À voir s’il est essentiel pour vous d’avoir de beaux imports dans vos projets. Perso, je ne l’utiliserais pas sur mes petits projets, mais sur des projets un peu gros, gérés sur un temps long avec une équipe qui bouge, ça peut être une bonne idée.

Bilan

Retour d’Oliver

Personnellement, je regrette que black mette sur une seule ligne un petit dictionnaire que je trouve plus lisible sur plusieurs lignes. Je suis déçu des quatre styles fournis par yapf, et je n’ai pas trouvé une superbe configuration magique. Finalement, sur notre projet c’est le bon vieux vénérable autopep8 qui est utilisé, car il ne change que très peu le code source que nous écrivons.

Sur notre projet on utilise black dans une ancienne version non taguée. L’intégration continue vérifie que le formatage est « standard ». Et contraint tous les contributeurs à utiliser la même version. Et par la même, limite la mise à jour de black. Malgré ce petit désagrément, j’ai configuré l’outil pour formater à chaque sauvegarde. Laisser un outil faire le formatage complet est très confortable. Avec une grosse base de code, j’ai vraiment autre chose à faire qu’aligner des commentaires et des valeurs de dictionnaires.

Retour de Philippe

J’ai testé pour vous les différents formatters sur un petit projet libre. Il s’agit d’un projet développé initialement par un stagiaire, que j’ai retravaillé avant que ma boite ne le mette en open source. Du coup, le style est un peu hétérogène, ça fait un bon candidat.

Voici les liens vers les diff sous GitHub :

reformatage avec black, zéro configuration ;
reformatage avec black, longueur de ligne à 120, pas de changements sur les chaînes (conservation des simple quote) et pas de magic-trailing-comma (je n’ai aucune idée de ce que ça fait) ;
reformatage avec blue, longueur de ligne à 120 ;
reformatage avec yapf, longueur de ligne à 110 ;
reformatage avec autopep8 ;
reformatage avec isort.

Mon point de vue général : sur un projet où je travaille seul, je vais pas utiliser de formateur de code. Je sais assez bien ce que j’aime et je suis relativement cohérent sur mon style. Sur un projet en équipe, c’est à réfléchir, mais je trouve le style de black/blue plutôt désagréable. Ma tentation de l’utiliser viendra donc de l’écart entre mon style et celui de mes coparticipants : s’il est grand, autant unifier avec un outil extérieur. Si on est proche, on garde comme ça.

À noter que j’ai un style pas forcément commun. J’aime bien que l’affichage ait une densité raisonnable. Par exemple, si je peux faire en sorte de voir la totalité d’une fonction sur un seul écran en tirant parti de lignes un peu plus longues, il y a un vrai bénéfice pour moi puisque je peux capturer en un coup d’œil l’ensemble du traitement. C’est pour ça que j’ai réglé la longueur maximum de ligne à 110 (ou 120 quand je me suis gouré) car c’est ce que j’affiche sans problème sur un portable 14 pouces. J’utilise aussi le formatage pour faire ressortir des similitudes dans le code, ce qui va s’opposer parfois à un formatage agressif tenant compte avec rigueur du niveau d’imbrication des structures.

Mon bilan sur ce projet-là :

isort, c’est gentil, j’aime bien, mais je vois pas trop l’intérêt. La valeur ajoutée est vraiment très faible, surtout que j’aime bien grouper tous les imports de la stdlib de Python sur une seule ligne (notion de densité de code évoquée plus haut), ce qu’il se refuse à faire (comme la majorité des gens) ;
autopep8, c’est assez peu envahissant. Ça me convient bien pour rectifier une base de code comme dans le projet que j’ai pris, sans pour autant tout péter mon style. J’aime bien ;
yapf, black, blue : honnêtement, je suis entre deux. Il y a clairement des gains en lisibilité par endroits, et d’autres où le code devient inutilement étalé sur plusieurs lignes et où la perte de densité me semble dommageable à la compréhension globale. Donc je suis réservé sur l’amélioration, mais pas hostile au concept en général.

Finalement, tout ça est vraiment très subjectif. Je comprends tout à fait pourquoi des gros projets ont adopté black, au moins, on évite ce type de discussion et le style reste tout à fait raisonnable.

Formateurs de docstring

`docformatter`

Le projet docformatter permet de reformater la partie docstring du code source.

Nous l’utilisons avec ces paramètres :

docformatter --wrap-summaries 444 --pre-summary-newline --in-place --recursive .

`pyment`

La documentation du code source Python se fait à l’aide des docstring standardisée par la PEP 257 (2001). Plusieurs types de docstring sont utilisés, les plus connus étant :

le format reStructuredText de la PEP 287 (2002) ;
le format recommandé par Google (exemple) ;
le format utilisé par le projet NumPy, connu sous le nom de numpydoc (exemple).

L’outil pyment permet de créer, corriger et de modifier ces représentations docstring.

L’auteur de pyment, Adel Daouzli (dadadel) nous avait présenté son outil dans son journal (2014). Mais Adel ne semble plus maintenir le code source ces derniers temps.

Comme plusieurs bugs sont corrigés dans des Pull Requests fights, j’ai donc pris en compte ces corrections et autres améliorations apportées et j’ai tout *mergé sur la branche olibre publiée sur un triple fork :

Attention, l’annotation des types (type hints Python 3.5) n’est pas prise en charge par pyment.

Génération de la documentation

C’est pratique quand la documentation de son code source et automatiquement générée. Deux outils intéressants :

Pdoc, successeur du bon vieux Epydoc ;
Sphinx, LE générateur de documentation Python le plus connu.

Attention, pour Pdoc, nous avons deux projets qui ont divergé : pdoc (l’original) et pdoc3 (le fork, plus actif).

Analyse statique de code

pylint

Pylint est je cite : « un outil qui recherche des erreurs dans le code Python, qui essaye d’imposer un standard de codage et qui cherche du code malodorant (code smells). Il peut aussi trouver certains types d’erreurs, faire des recommandations sur la façon dont un bloc peut être réorganisé et détaille la complexité du code ».

Pylint est un projet ancien (plus de 15 ans), qui analyse le code Python dans plusieurs optiques différentes :

conformité à un style de codage, le fameux pep8 plus quelques petits détails supplémentaires ;
analyse de la complexité du code (nombre de chemins d’exécution dans une fonction, etc.) ;
erreurs de codage ;
améliorations possibles (suppression de parenthèses, simplifications…).

Chaque problème reporté peut-être désactivable, en ligne de commande ou via une variété de fichiers de configuration (.pylintrc, pyproject.toml ou setup.cfg). On peut aussi dans le code activer ou désactiver spécifiquement des configurations, au niveau du fichier, d’une fonction, d’un bloc de code ou, tout simplement, d’une ligne.

Retour de Philippe

J’ai fait une tentative sur le même projet, sxtool. J’ai un peu galéré pour le lancer et je n’ai pas trouvé la ligne magique où il comprend tous les imports de mon projet. La première exécution m’a retourné 1 500 lignes d’erreurs. La très grande majorité sont des erreurs de style (lignes trop longues, nommage des variables pas en snake_case, docstring manquantes, absence de fin de ligne en fin de fichier…). En désactivant les erreurs de style les plus courantes, je tombe sur quelques erreurs plus intéressantes du type :

trop de return dans une fonction ;
trop de chemins d’exécution dans une fonction ;
variables ou import inutilisés ;
redéfinition de nom pré-intégrés, format, file ;
clause d’attrapage d’exception trop large ;
else inutile après un return.

Les problèmes de code signalés sont légitimes. Ils correspondent à du code peu lisible et des erreurs liées au manque de familiarité avec Python de l’auteur initial. Le code correspondant a été développé par un stagiaire qui débutait en Python.

Mais, une fois ce constat fait, il est totalement irréaliste d’imaginer passer du temps à rectifier le code en question. Ce serait très coûteux en temps, et le bénéfice reste modeste. Exiger du code avec un style parfaitement conforme est l’apanage de quelques rares projets ou entreprises de logiciel très exigeantes. Le reste du monde vit très bien avec du code aux styles complètement hétérogènes (et je suis le premier à le regretter). Essayez de le mettre en place dans une équipe et vous verrez ! C’est ce qui fait que les linters Python, bien qu’existant depuis longtemps, ne sont pas plus populaires que cela. Honnêtement, se faire rappeler à l’ordre par un outil parce qu’il manque une espace après une virgule, c’est très pénible.

L’approche récente du reformatage prise par black et consorts résout ce problème de façon plus pérenne.

Concernant l’analyse de la complexité du code, j’aime beaucoup le concept, mais j’imagine mal le mettre en place. Sur mes projets solo, je suis déjà attentif à la complexité et la lisibilité, donc il ne m’apportera rien. Sur des projets en équipe, les gens qui vont être favorables à la mise en place d’un tel outil sont justement ceux qui sont conscients du problème de la complexité du code, et qui ont déjà tendance à ne pas privilégier ce style. Les non-favorables tombent vite dans des guerres de chapelle (« mais si, sept if imbriqués, c’est très bien ! ») et on ne s’en sort pas. Les cas qui me paraissent réalistes pour la mise en place seraient ceux où des managers sont conscients des bénéfices d’un code peu complexe et imposent l’outil. Ou alors une équipe qui aborde une base de code héritée importante et qui souhaite cibler les modules où le risque de bug est plus élevé qu’ailleurs.

Restent, enfin, les erreurs que peut détecter pylint. On en trouve la liste dans la documentation de référence. Les classes d’erreur ont l’air intéressantes bien que certaines soient un peu louches à mon goût : je vois pas bien comment du code pourrait tourner avec certaines des erreurs qui sont signalées. J’imagine qu’elles sont pourtant toutes basées sur des cas réels.

Voici quelques erreurs prises au hasard :

nonlocal-and-global (E0115): Emitted when a name is both nonlocal and global ;
not-in-loop (E0103): Used when break or continue keywords are used outside a loop ;
return-in-init (E0101): Used when the special class method init has an explicit return value ;
inherit-non-class (E0239): Used when a class inherits from something which is not a class ;
…

pylint peut être lancé avec -E pour ne signaler que les erreurs de ce type. Serait-ce parce que c’est sa plus grande valeur ajoutée ?

Mon bilan

Le concept est intéressant mais le côté pédant de l’outil est désagréable et les autres bénéfices restent trop réduits. Je pense que mettre en place des revues de code sera plus efficace et plus constructif que de passer un projet à pylint.

pyflakes

PyFlakes est avec pylint un des anciens linter/checker de code Python : les premières versions datent de 2009. Le principe est simple : un programme simple qui vérifie les fichiers source Python à la recherche d’erreurs. En complément, le README ajoute il ne va jamais se plaindre à propos du style, il va essayer très très intensément de ne jamais émettre de faux positifs .

Retour de Philippe

Tout ça est très prometteur. Par contre, la documentation ajoute que pyflakes est plus limité dans les types d’erreurs qu’il peut trouver, car il inspecte l’arbre de syntaxe plutôt qu’importer le code.

Voyons voir ce que ça donne, je prends le même cobaye, sxtool. Pas de problème à l’installation, pas de problème à l’exécution. Il me signale une cinquantaine d’erreurs qui ne correspondent en fait qu’à deux cas :

un nom est importé mais pas utilisé ;
une variable ou un argument est inutilisé.

Intéressant, mais pas fantastique. Mon projet n’a pas d’erreur manifeste, c’est cool.

Je jette un coup d’œil à la documentation pour en savoir plus sur le potentiel de pyflakes pour découvrir qu’il n’y a pas de documentation. Impossible de savoir quelles classes d’erreurs sont détectées. La lecture du ChangeLog laisse entrevoir quelques idées mais sans plus.

Rien non plus sur la configuration, on ne peut pas ignorer certains fichiers ou annoter une ligne pour ignorer une erreur. Il me semble que c’est parce que pyflakes ne s’utilise plus tel quel. Le projet a fait cause commune avec un autre linter, pep8, pour former flake8, un lanceur de linter/checker Python. flake8 est couvert dans la suite de la dépêche et c’est lui qui permet de configurer finement la vérification d’un fichier et la désactivation de certaines erreurs. Par contre, la documentation de flake8 n’en dit pas plus sur les types de vérifications effectuées par pyflakes.

En conclusion, je n’ai pas pu mettre en évidence l’intérêt de pyflakes, mais je sais qu’il a plutôt une bonne réputation dans la communauté Python. Mon projet cobaye est aussi assez simple, il n’utilise que très peu de fonctionnalités de Python. Sur des projets plus élaborés fonctionnellement, j’imagine qu’il peut trouver des erreurs intéressantes.

Si vous utilisez pyflakes et que vous connaissez sa valeur, n’hésitez pas à nous le partager dans les commentaires.

flake8

Flake8 est un lanceur de linter. Il est né du rapprochement des projets pyflakes et pep8 (qui est devenu pycodestyle au passage). La version de base fait du 3-en-1 :

PyFlakes, la recherche d’erreurs générales ;
pycodestyle, les vérifications de style façon pep8 ;
le script McCabe de Ned Batchelder, la vérification de la complexité du code.

Flake8 exécute tous les outils en lançant la commande unique flake8. Il affiche les avertissements par fichiers dans une sortie commune.

Il ajoute également quelques fonctionnalités :

les fichiers qui contiennent cette ligne sont ignorés :

# flake8 : noqa

les lignes qui contiennent un commentaire # noqa à la fin n’émettront pas d’avertissement ;
vous pouvez ignorer des erreurs spécifiques sur une ligne avec # noqa : , par exemple, # noqa : E234. Plusieurs codes peuvent être donnés, séparés par une virgule, le jeton noqa n’est pas sensible à la casse, les deux points avant la liste des codes sont nécessaires, sinon la partie après noqa est ignorée ;
des hooks Git et Mercurial ;
extensible via les points d’entrée flake8.extension et flake8.formatting.

Configuration

Exemple de fichier de configuration :

[flake8]
max-line-length = 88
select = C,E,F,W,B,B9
ignore = E203, E501, W503
exclude = __init__.py

Ce contenu peut être glissé dans un fichier .flake8, ou dans tox.ini ou encore un setup.cfg, ce qui permet de s’intégrer dans un fichier de config partagé avec d’autres outils de l’écosystème de packaging python.

La force de flake8, c’est qu’on peut facilement rajouter des plugins pour compléter son travail. Il existe des plugins pour tout un tas de vérifications supplémentaires, pour lancer d’autres outils ou pour adapter le format de sortie à des services spécifiques.

Retour de Philippe

flake8 a une bonne réputation dans l’écosystème Python. Je l’ai essayé toujours sur mon projet cobaye sxtool. Je n’ai récupéré que des erreurs de style, et une ou deux variables non utilisées. En forçant le test de complexité à maximum 5, j’ai récupéré une erreur due à la complexité trop élevée d’une fonction.

Je suis plutôt déçu. Les erreurs de style ne m’intéressent pas, je les traiterai avec black. Mais, pas moyen de les ignorer toutes d’un coup. Pas d’erreurs de codage reporté, c’est bien pour mon projet, mais je n’ai toujours aucune idée du type d’erreur qui peut être détecté. Pour la complexité, pylint avait trouvé plus de fonctions nécessitant un retravail, je suis également déçu.

L’écosystème de plugin est réputé riche, mais là encore, la documentation n’en mentionne presque aucun. Vous pouvez piocher dans la longue liste de awesome-flake8-extensions pour trouver votre bonheur. On trouve pas mal de plugins pour lancer d’autres outils dans flake8, genre pylint ou mypy ou encore bandit. On trouve aussi pas mal de plugins pour ajuster le format de sortie à un besoin spécifique, et encore des plugins pour faire quelques vérifications très ciblées.

bandit

Bandit est un outil conçu pour trouver de failles de sécurité connues dans du code Python. Comme Pylint, il analyse les fichiers Python en construisant leur arbre syntaxique (AST) et exécute un ensemble de vérification sur ce dernier. Le projet existe depuis 2015 et a reçu plus de 3000 étoiles GitHub.

Bandit est extensible par plugin, à la fois pour rajouter des vérifications ou pour modifier le format de sortie. On le configure par un fichier en YAML ou par des directives dans les fichiers ou lignes de code concernées.

Retour de Philippe

Avant de lancer le projet, je note déjà que la documentation est bien faite et couvre les aspects qui m’intéressent facilement. Alors, toujours sur mon projet sxtool, que donne bandit ?

 > bandit -r sxtool

[main]  INFO    profile include tests: None
[main]  INFO    profile exclude tests: None
[main]  INFO    cli include tests: None
[main]  INFO    cli exclude tests: None
[main]  INFO    running on Python 3.8.8
Run started:2021-05-15 16:49:52.455989

[...]

--------------------------------------------------
>> Issue: [B318:blacklist] Using xml.dom.minidom.parse to parse untrusted XML data is known to be vulnerable to XML attacks. Replace xml.dom.minidom.parse with its defusedxml equivalent function or make sure defusedxml.defuse_stdlib() is called
   Severity: Medium   Confidence: High
   Location: .\src\utils.py:20
   More Info: https://bandit.readthedocs.io/en/latest/blacklists/blacklist_calls.html#b313-b320-xml-bad-minidom
19              try:
20                  self.tree = dom.parse(fileName)
21              except sax.SAXParseException :

--------------------------------------------------

Code scanned:
        Total lines of code: 3073
        Total lines skipped (#nosec): 0

Run metrics:
        Total issues (by severity):
                Undefined: 0.0
                Low: 5.0
                Medium: 1.0
                High: 1.0
        Total issues (by confidence):
                Undefined: 0.0
                Low: 0.0
                Medium: 0.0
                High: 7.0
Files skipped (0):

Donc sept problèmes majeurs! Quand même! Si vous voulez voir les détails, c’est ici.

Les catégories de problème trouvés :

utilisation de assert, alors qu’en compilant avec -O, les asserts disparaissent ;
lancement d’une commande dans un shell de façon non sécurisée ;
utilisation d’une bibliothèque non sécurisées pour parser du XML, notamment vulnérables à de l’injection de code.

Tout ça est présenté dans un magnifique rapport, avec des belles couleurs selon le niveau de vulnérabilité estimé. Et on peut aussi en faire une version html, ou CSV. Pour chaque erreur, un lien vers la documentation indique la raison pour laquelle c’est un risque de sécurité, et pour la plupart la marche à suivre pour le corriger !

Conclusion : j’adore ! Le niveau de finition est très agréable !

Annotation de type

Depuis 2006 et la version 3.0 de Python, il est possible de rajouter des annotations au code Python. Et depuis 2009, Dropbox livre un outil de vérification d’annotations de type pour Python : mypy.

Au fil des versions de Python, les annotations de type se sont généralisées (d’abord des arguments de fonctions à maintenant toutes les variables et attributs de classes) et simplifiées dans leur usage. Mypy a aussi continué à évoluer, permettant des définitions de plus en plus fines des types pour décrire un contenu. En parallèle, le nombre de projet avec du typage disponible n’a cessé d’évoluer, que ce soit directement dans le projet typeshed qui regroupe les informations de types (typing stubs) de la lib standard ou alors livré en même temps avec le paquet concerné (comme Flask mentionné récemment dans une dépêche), ou encore via un paquet séparé qui ne fournit que les stubs (cas de PyQt5-stubs et django-stubs qui fournissent les stubs de respectivement PyQt5 et django).

Pour faire bref, ajouter des annotations de type à votre code va apporter les avantages suivants :

les annotations créent une forme de documentation très compact des arguments et résultats des fonctions ;
les annotations permettent de garantir que votre code est utilisé de la bonne façon ; corollaire, ça permet de découvrir des bugs difficiles à trouver autrement, quand une fonction/méthode est utilisée de façon incorrecte, ou quand l’ensemble des types possibles d’une variable a mal été pris en compt ;
les IDE peuvent utiliser les annotations de types pour proposer une complétion plus intelligente.

Bien sûr, tout cela a un coût :

annoter une base de code est très rapide et simple au début, mais peut devenir assez fastidieux et chronophage si on vise le 100 % annoté. Heureusement, les outils fonctionnent très bien avec du code partiellement annoté ;
pour les cas complexes, il faut se pencher pas mal sur la documentation. C’est assez chronophage ;
certaines constructions dynamiques de Python, ou tout simplement la logique de votre code peut être impossible à capturer avec du typage statique ;
certaines annotations sont longues à écrire, et alourdissent la lisibilité du code : des définitions de fonctions vont passer de une ligne à plusieurs à cause de cela ;
la vérification de la cohérence globale, c’est un outil de plus à lancer, qui plus est un outil qui n’est pas forcément rapide, donc ça ralentit le processus de développement global.

Depuis quelques années, Dropbox et Facebook/Instagram se sont mis au typage statique de tout leur code, et les retours des développeurs sont très positifs. Il y a eu plusieurs sessions au PyCon US sur ce sujet.

Pour comprendre l’intérêt du typage statique en Python, prenons un exemple simple:

def is_equal(a, b):
    if a == b: 
        return True

Bien qu’imparfaite, cette fonction va plutôt bien marcher sur tout ce qui implémente correctement l’égalité : les booléens, les entiers, les chaînes de caractères, etc. C’est pas mal, et ça veut aussi dire qu’on peut facilement passer à côté d’un bug. Voyons en pratique :

def print_is_equal(a, b):
    if is_equal(a, b):
        print('Egalité pour', a)
    else:
        print('Différence:', a, b)

>>> print_is_equal(1, 1)
Egalité pour 1

>>> print_is_equal(1, 2)
Différence: 1 2

>>> print_is_equal('abc', "abc")    # deux représentations de la même chaîne de caractère sont identiques
Egalité pour abc

>>> print_is_equal(0.3, 0.3)
Egalité pour 0.3

>>> print_is_equal(0.3, 0.2 + 0.1)
Différence: 0.3 0.30000000000000004

Oups ! Et oui, comme 0.1 se représente mal en base 2, il génère des erreurs dans les calculs. Donc, il faut éviter d’utiliser notre belle fonction avec des flottants. C’est ce que peut nous aider à faire les vérificateurs d’annotations de type.

Si on rajoute un brin de documentation et des annotations de type, voilà ce que ça donne :

def is_equal(a: int, b: int) -> bool:
    '''Compare two integers and return True if they are equal'''
    if a == b: 
        return True


def print_is_equal(a: int, b: int) -> None:
    '''Display whether two numeric values are equal'''
    if is_equal(a, b):
        print('Egalité pour', a)
    else:
        print('Différence:', a, b)


print_is_equal(1, 1)
print_is_equal(1, 2)
print_is_equal(0.3, 0.2 + 0.1)

Et lorsqu’on passe ce programme à travers mypy :

>mypy src\is_equal.py
src\is_equal.py:1: error: Missing return statement
src\is_equal.py:16: error: Argument 1 to "print_is_equal" has incompatible type "float"; expected "int"
src\is_equal.py:16: error: Argument 2 to "print_is_equal" has incompatible type "float"; expected "int"
Found 3 errors in 1 file (checked 1 source file)

Il détecte bien, d’une part que la fonction est utilisée de façon incorrecte avec des flottants, d’autre part que nous avons oublié un return : la fonction renvoie None dans le cas d’une inégalité.

À noter que la documentation des deux fonctions est correcte sans être assez précise: two numeric value peut aussi bien faire référence à deux flottants qu’à deux entiers. De même, pour is_equal(), ce que retourne la fonction en cas d’inégalité n’est pas documenté et va fonctionner dans tous les tests qui ne vérifient pas exclusivement l’égalité àFalse. Le développeur avait sûrement en tête de retourner False, mais difficile d’en être sûr. C’est l’intérêt des annotations de type : elles obligent à plus de rigueur et elles capturent l’intention du développeur mieux que de la documentation.

Si vous voulez vous mettre à l’annotation de type dans Python, on trouve pas mal de ressources sur Internet, dont une conférence en français réalisée par un certain Philippe F.

Penchons-nous maintenant sur les outils de l’annotation de type.

`mypy`

Mypy est la référence en termes de vérification de typage. C’est l’émergence de mypy qui a permis aux annotations de s’imposer dans l’écosystème Python. L’outil est maintenu par l’équipe Python de Dropbox (dans laquelle Guido Van Rossum a fait un séjour assez long). Le projet est très dynamique, avec des nouvelles versions fréquentes, qui permettent de pousser le typage de plus en plus finement. Mypy fournit une documentation de bonne qualité pour aider à se mettre au typage. L’outil dispose d’un large jeu d’option, qui permettent d’ajuster assez finement le niveau de typage qu’on souhaite, de très léger à très exigeant. C’est un peu comme les options de compilation de gcc, il y en a pour tous les goûts. Tout ça peut se régler aussi par un beau fichier de config au format ini.

Mypy gère les annotations Python 3 (directement dans le code) ou Python 2 (sous forme de commentaire). Comme pour les vérificateurs de code, il est possible directement depuis le code d’ignorer une erreur en ajoutant un commentaire # type: ignore. On peut même préciser le type d’erreur à ignorer plus précisément.

Ça se lance en ligne de commande, mais comme l’outil est lent sur des grosses bases de code, on peut lancer un serveur dmypy qui va garder en cache les résultats intermédiaires et vérifier le code beaucoup plus vite.

Ah oui, et c’est écrit en Python, c’est pour ça que c’est lent ! (attention un troll velu s’est caché dans la phrase précédente, à toi de le débusquer sans le nourrir !).

Retour de Philippe

Sans surprise, je suis un grand fan de l’annotation de type et j’utilise mypy intensément. Il s’installe très simplement avec pip. À l’usage, sur mes projets, au fur à mesure que j’y rajoute les annotations de type, j’ai constaté que :

c’est chronophage, notamment au début, où on se perd dans la documentation, et à la fin quand on essaye d’être 100 % typés, on croise des cas vraiment complexes à annoter ;
c’est bien documenté et on trouve facilement de l’aide, sur le site de mypy ou sur stackoverflow ;
il faut parfois modifier le code pour aider mypy avec quelques asserts, c’est sans conséquence et dans un certain nombre de cas, ça oblige à se poser les bonnes questions : est-ce que ma variable trucmuche peut encore être à None ou pas dans cette partie de code ?
je n’ai pas l’impression d’avoir trouvé des gros bugs avec ça, par contre, je sais que ma base de code est beaucoup plus fiable. Au boulot, j’ai récemment fait du « refactoring » sur des « callback » un peu poilus et j’étais content que mypy me pointe tous les endroits où je devais intervenir ;
l’aspect documentation compacte est incroyablement agréable. Mes collègues qui arrivent sur mes projets avec annotation de type me disent aussi qu’ils ont beaucoup plus de facilité pour comprendre le code. J’ai retravaillé un petit projet à moi de 15 ans d’âge récemment. J’étais à moitié perdu dans mon code de l’époque. J’ai décidé de le typer pour m’y retrouver mieux et ça a fait une vraie différence.

Sur ce petit projet de 15 ans d’âge, je vous montre le code avant. C’est un tout petit bout de code qui doit déplacer une pièce d’un jeu.

    def move_tile(self, pid, d):
         if not self.move_enabled: 
             return

        self.map.move( pid, d )
        self.board.move( pid, d )

        [...]

En revoyant ce code, je ne me rappelais plus ce qu’était pid et d. Avec les annotations, ça donne :

    def move_tile(self, pid: str, d: Tuple[int, int]) -> None:
         if not self.move_enabled: 
             return

        assert self.map
        self.map.move( pid, d )
        self.board.move( pid, d )

        [...]

Avec ces informations, j’ai recollé les morceaux: pid est un identifiant de pièce (piece-id) et d est le delta de déplacement, sous forme de deux entiers.

`pyre`

Pyre est l’implémentation de Facebook pour la vérification de typage en Python. Écrite en OCaml, c’est un dérivé d’un moteur d’inférence de type qu’ils avaient déjà construit pour PHP. Au niveau de la vérification du typage statique, ils se sont calés sur mypy. Les commentaires pour supprimer une erreur façon mypy (# type: ignore) sont d’ailleurs supporté aussi par pyre.

La documentation est correcte et le contrôle du niveau de vérification est un peu moins fin que mypy. En gros, on a vérification stricte ou pas stricte.

Pyre a la réputation d’être rapide pour valider beaucoup de lignes de code : ça fait quand même tourner plus d’un million de lignes de code chez Facebook. On peut notre quelques différences mineures d’interprétation entre mypy et pyre. En conséquence, il vaut mieux éviter d’utiliser les deux outils conjointement sur une base de code. Il y a un choix à faire.

À noter que Pyre fournit aussi Pysa qui fait des vérifications de sécurité par analyse de code. Il vérifie qu’une chaîne de caractère sous contrôle de l’utilisateur (genre, un paramètre d’url) ne peut pas atteindre un composant critique (genre une écriture en base de donnée) sans passer par un désinfectant (« sanitizer »). Ce travail est fait en s’appuyant aussi sur les annotations, cette fois un peu moins orienté typage statique.

Retour de Philippe

Cette dépêche est l’occasion de faire un petit test de pyre. D’après la documentation, ça marche bien sous Linux et MacOs mais c’est expérimental sous Windows, et ça ne fonctionne que grâce a WSL (Windows Subsystem for Linux). Sur ma machine Windows, j’ai donc étrenné mon WSL Ubuntu avec pyre : ça se passe sans accroc, exactement comme décrit dans la documentation.

Pour mes projets PyQt, il n’interprète pas les stubs PyQt comme mypy. Du coup, du code avec 0 erreur sous mypy génère quelques erreurs sous pyre. Autre petit souci, la gestion de la valeur None ne se fait pas comme sous mypy, donc mon code qui plaît à mypy lui semble poser problème.

En dehors de ça, la vérification est rapide et les diagnostics sont clairs. Sur l’exemple que j’ai donné sur l’annotation, ça donne :

(pyre-env) $ pyre --source-directory . check
ƛ Using virtual environment site-packages in search path...
ƛ Setting up a `.pyre_configuration` with `pyre init` may reduce overhead.
ƛ Found 2 type errors!
linuxfr.py:5:8 Incompatible return type [7]: Expected `bool` but got implicit return value of `None`.
linuxfr.py:16:15 Incompatible parameter type [6]: Expected `int` for 1st positional only parameter to call `print_is_equal` but got `float`.

Il a trouvé en gros les mêmes erreurs que mypy, sauf qu’il s’est arrêté au premier argument incorrect de la fonction alors que mypy a eu la générosité de signaler que les deux arguments étaient passés en float plutôt que en int.

En conclusion, je pense que c’est un bon projet même si je vais rester avec mypy. La bataille entre mypy et pyre, c’est un peu la bataille entre git et mercurial : mypy et git ont gagné depuis longtemps à ce qu’il me semble, mais pyre et mercurial restent de très bons outils.

`monkeytype`

Plutôt que d’annoter une base de code à la main, pourquoi ne pas la faire tourner en production et regarder quels types sont effectivement utilisés ? C’est ce que fait monkeytype, il vous aide à collecter les types lors de l’exécution du code, puis à les appliquer sous forme de typage statique sur une base de code. L’outil est maintenu par Instagram et a plus de 3 000 étoiles sur GitHub.

Évidemment, la collecte durant l’exécution du code ralentit énormément le programme (genre 10 fois plus lent). À partir des résultats de la collecte, Monkeytype génère un fichier stub de tous les types qu’il a rencontrés. Ceux-ci ne représentent certainement pas tous les contextes possibles d’exécution du code, il est donc essentiel de faire une relecture pour compléter et vérifier la cohérence du résultat. Cela dit, Monkeytype peut faire gagner pas mal de temps pour démarrer l’annotation d’une base de code.

Retour de Philippe

Je vais tester monkeytype sur le cas très simple du is_equal.py que j’ai présenté en version non annotée. Première, étape, il faut isoler le code à annoter dans un module. Je déplace donc les trois lignes contenant les appels à print_is_equal() dans un fichier run_is_equal.py . Après, l’utilisation est simple : je remplace Python par monkeytype et hop, ça tourne.

> monkeytype run run_is_equal.py
Egalité pour 1
Différence: 1 2
Différence: 0.3 0.30000000000000004

Je constate apparition d’un fichier monkeytype.sql3 dans mon répertoire, c’est bon signe.

Il y a plusieurs façons de générer des annotations. La première, c’est de générer un fichier stub à part. Je lui demande de faire ça pour le module is_equal:

>monkeytype stub is_equal
from typing import (
    Optional,
    Union,
)

def is_equal(a: Union[int, float], b: Union[int, float]) -> Optional[bool]: ...

def print_is_equal(a: Union[float, int], b: Union[float, int]) -> None: ...

Voilà, je peux stocker ce résultat dans un fichier is_equal.pyi et mon code est vérifiable. On note que l’exécution du code a mis en évidence que les fonctions étaient appelées avec entiers ou des flottants, et que is_equal() retourne un booléen ou None. Comme ce n’est pas l’intention de départ, c’est bien de relire les stubs avant de les ajouter aveuglément au code.

On peut aussi demander à monkeytype de modifier directement le code pour ajouter les annotations. C’est mon mode préféré d’utilisation puisqu’on voit bien le diff avec git.

>monkeytype apply  is_equal
from typing import Optional, Union

def is_equal(a: Union[float, int], b: Union[float, int]) -> Optional[bool]:
    '''Compare two integers and return True if they are equal, False if not'''
    if a == b:
        return True

def print_is_equal(a: Union[int, float], b: Union[int, float]) -> None:
    '''Display whether two numeric values are equal'''
    if is_equal(a, b):
        print('Egalité pour', a)
    else:
        print('Différence:', a, b)

Il a modifié le fichier sur place et m’a aussi montré le code sur la sortie standard.

À noter que si vous avez déjà des annotations, monkeytype ne va pas y toucher, mais vous pouvez lui demander de montrer la différence entre vos annotations et ce qu’il a vu passer.

En conclusion, monkeytype est très pratique pour annoter du code qui a déjà des tests et une utilisation en production. On gagne un temps vraiment important et l’outil est mature.

Tests unitaires

Historiquement, nous avons unittest. D’autres alternatives intéressantes : nose et pytest.

`unittest`

unittest est la bibliothèque de test unitaire incluse par défaut dans Python. Le fonctionnement est calqué sur les bibliothèques de test du genre junit (première version), basée sur des classes et des fonctions spécifiques d’assertion.

def incremente(x):
    return x + 1

class TestIncremente(unittest.TestCase):
    def test_incremente(self):
        self.assertEqual(incremente(3), 4)

C’est une très bonne bibliothèque de test, qu’on peut utiliser sur de très gros projets sans souci. Au-delà de ses fonctionnalités classiques, elle a des fonctionnalités méconnues mais bien sympathiques. Par exemple, il est possible de tester le comportement d’une fonction en faisant varier les paramètres. L’approche choisie est « pythonesque » puisqu’elle s’appuie sur les gestionnaires de contexte. Si on complète l’exemple précédent, ça donne :

def incremente(x):
    return x + 1

class TestIncremente(unittest.TestCase):
    def test_incremente(self):
        self.assertEqual(incremente(3), 4)

    def test_many_increments(self):
        for value_in, value_out in [
            (1, 2),
            (-100, -99),
            (-1, -2),  # oups, celui-la va échouer
            (-1, 0),
            (0, 1),
            (100, 99),  #  celui-la va échouer aussi
        ]:
            with self.subTest(value_in=value_in, value_out=value_out):
                self.assertEqual(incremente(value_in), value_out)

Et à l’exécution :

> python -m unittest test_incremente.py
======================================================================
FAIL: test_many_increments (test_incremente.TestIncremente) (value_in=-1, value_out=-2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_incremente.py", line 22, in test_many_increments
    self.assertEqual(incremente(value_in), value_out)
AssertionError: 0 != -2
======================================================================
FAIL: test_many_increments (test_incremente.TestIncremente) (value_in=100, value_out=99)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_incremente.py", line 22, in test_many_increments
    self.assertEqual(incremente(value_in), value_out)
AssertionError: 101 != 99
----------------------------------------------------------------------
Ran 2 tests in 0.003s

FAILED (failures=2)

On voit clairement quelles valeurs ont posé problème dans le rapport de test.

Autre aspect appréciable, unittest fait de gros effort pour vous aider à comprendre ce qui diffère lorsque vous comparez deux chaînes de caractères ou deux listes. Par exemple, en complétant le code précédent avec deux tests supplémentaires :

    def test_list_diff(self):
        self.assertEqual([1, 2, 3, 4], [1, 3, 4]) # il manque la valeur 2

    def test_str_diff(self):
        self.assertEqual('abcdef', 'abdef') # il manque le caractère 'c'

Le rapport d’exécution :

======================================================================
FAIL: test_list_diff (test_incremente.TestIncremente)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_incremente.py", line 26, in test_list_diff
    self.assertEqual([1,2,3,4], [1,3,4])
AssertionError: Lists differ: [1, 2, 3, 4] != [1, 3, 4]

First differing element 1:
2
3

First list contains 1 additional elements.
First extra element 3:
4

- [1, 2, 3, 4]
?     ---

+ [1, 3, 4]

======================================================================
FAIL: test_str_diff (test_incremente.TestIncremente)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_incremente.py", line 29, in test_str_diff
    self.assertEqual('abcdef', 'abdef')
AssertionError: 'abcdef' != 'abdef'
- abcdef
?   -
+ abdef

`pytest`

pytest est un projet plus récent. Il permet de décrire les tests d’une manière plus « pythonesque », sans avoir à implémenter de classe ni à utiliser des méthodes spécifiques d’assertion.

def incremente(x):
    return x + 1

def test_incremente():
    assert incremente(3) == 4

pytest est un outil de test très élaboré. Parmi ses fonctionnalités notables, on peut citer :

la découverte automatique des fichiers de test ;
une compatibilité avec unittest et nose, permettant une migration en douceur ;
la possibilité d’affecter un ou plusieurs labels à un test, ce qui permet ensuite de lancer des groupes de test spécifiques assez facilement ;
un système d’initialisation des tests très élaboré, qui permet de partager aisément une ou plusieurs ressources entre plusieurs tests (pratique par exemple pour des opérations de créations de ressources coûteuses, qu’on souhaite partager entre plusieurs tests) ;
les tests paramétrés, c’est-à-dire la possibilité de lancer le même test avec un jeu de valeur ;
une ligne de commande élaborée, qui permet par exemple de lancer uniquement les derniers tests ayant échoué (très pratique en phase de debug) ;
un jeu d’extension via des plugins très pratiques. On en trouve pour tout, par exemple, pytest-cov permet de faire de la couverture de code

Vous l’aurez compris, pytest, c’est le niveau au-dessus du test. Si vous rencontrez des limitations avec unittest, c’est le bon candidat à essayer. La documentation est de bonne qualité. Par contre, la mise en œuvre des tests utilise une approche différente de la famille de unittest, qui peut déstabiliser dans un premier temps.

`nose`

nose ajoute à unittest un lanceur et des extensions.

L’outil n’est plus maintenu, mais un projet nose2, fonctionnant avec les versions de Python maintenues fournit quasiment les mêmes services.

https://nose2.readthedocs.io/en/latest/differences.html

`ward`

ward reprend beaucoup des concepts de pytest notamment sur l’initialisation des tests (les fixtures) et leur découverte. L’auteur a, d’ailleurs, un plugin pour pytest qui propose une partie du rendu de ward. Ce qui distingue ward, c’est la façon d’écrire un test avec une description plutôt qu’un nom, et un affichage très soigné visuellement : il tire parti des couleurs d’avant-plan et d’arrière-plan, ainsi que de quelques symboles unicode pour faire un rendu riche en détails, en particulier sur l’analyse des différences :

Notre exemple donne avec ward :

from ward import test

def incremente(x):
    return x + 1

@test("incremente une valeur _positive_")
def _():
    assert incremente(33) == 34

`unittest.mock`

Pour isoler la partie de code que l’on souhaite tester, il est souvent nécessaire de construire un environnement spécifique. Un véritable environnement fonctionnel, ou des simulateurs de composants, ou encore des « mocks » : des simulateurs au comportement extrêmement simplifié.

La bibliothèque standard unittest.mock permet de créer de tels objets, et de s’en servir pour patcher ou instrumenter son environnement.

Les objets Mock, PropertyMock, NonCallableMock permettent, par combinaison, de construire des objets en leur associant un comportement simple. MagicMock et NonCallableMagicMock vont fonctionner de la même manière, mais leur construction sera construite automatiquement par le code testé.

Il est possible de remplacer en partie un objet, de le faire passer pour l’instance d’une classe particulière (isinstance), de générer une séquence de résultats ou encore de lever une exception.

Après exécution il est possible de vérifier que les appels se sont déroulés comme attendu.

def process(value, database=None):
    result = value ** 2
    if database is not None:
        saved = database.save(value, result)
        if not saved:
            raise Exception("Database problem")
    return result

from unittest import mock

def test_database_is_called():
    database = mock.NonCallableMock()
    database.save = mock.MagicMock(return_value=True)
    result = process(2, database)
    # La base de donnée a bien été appelé.
    # Une seule et unique demande de sauvegarde a été faite
    # avec pour argument la donnée d’entrée et le résultat
    database.save.assert_called_once_with(2, result)

En sus l’utilitaire create_autospec permet de générer un mock répondant aux spécifications d’un objet particulier. Python 3.7 a également ajouté la fonction seal pour verrouiller les mocks dans un état donné.

Enfin les mocks peuvent être placés temporairement en remplacement de classes et de fonctions par le biais de patchs. Par défaut la fonction construit un MagicMock. Elle peut s’utiliser comme un décorateur ou comme une fonction contextuelle (avec l’opérateur with).

import os

def clean_up_config():
    os.remove("foo/bar")
    os.remove("foo/baz")

from unittest import mock

@mock.patch("os.remove")
def test_clean_up(os_remove_mock):
    clean_up_config()
    # Vérifie que la requête de supression des
    # deux fichiers à bien été faite
    calls = [mock.call("foo/bar"), mock.call("foo/baz")]
    os.remove.assert_has_calls(calls, any_order=True)

Il existe encore d’autres utilitaires, qui permettent par exemple de patcher temporairement des dictionnaires, ou de simuler la fonction open. Voir la documentation complète.

`pytest-mock`

pytest-mock fournit la même API par le biais d’une fixture pytest. Par ce biais, le contexte temporaire est géré automatiquement, et les retours d’erreurs sont également améliorés (en y nettoyant les traces d’exception induites par l’environnement de test).

import os
from unittest import mock

def clean_up_config():
    os.remove("foo/bar")
    os.remove("foo/baz")

def test_clean_up(mocker):
    mocker.patch("os.remove")
    clean_up_config()
    # Vérifie que la requête de supression des
    # deux fichiers à bien été faite
    calls = [mock.call("foo/bar"), mock.call("foo/baz")]
    os.remove.assert_has_calls(calls, any_order=True)

Dans cet exemple de code, l’argument mocker est un appel à une extension de pytest nommée pytest-mock qui permet de mettre en place le mécanisme de mock pour la durée du test en question.

`hypothesis`

Hypothesis est une implémentation de QuickCheck pour Python (et quelques autres langages).

Cette bibliothèque permet de décrire dans les tests pytest les propriétés qu’une fonction doit avoir. Sa combinatoire en entrée et ses invariants. À l’exécution du test elle génère automatiquement des entrées visant à trouver des effets de bord. Les jeux de test générés sont mis en cache et réutilisés.

C’est donc un complément à des tests standards.

La bibliothèque fournit un ensemble de stratégies pour différents type de données, allant des nombres, aux chaînes de caractères, en passant par les tableaux numpy, ainsi que des outils pour les combiner. Elle permet également de décrire des séquences de changements, que l’on construit à l’aide d’un automate à état, afin de vérifier des systèmes plus complexes.

Voici un exemple permettant de se faire une idée, avec la résolution d’une équation quadratique.

def solve_poly2(a, b, c):
    """Résout l'équation ax^2 + bx + c == 0"""
    delta = b**2 - 4.0 * a * c
    results = []
    if delta > 0:
        results.append((-b + delta**0.5) / (2.0 * a))
        results.append((-b - delta**0.5) / (2.0 * a))
    elif delta == 0:
        results.append(-b / (2.0 * a))
    return results

import pytest
import numpy
from hypothesis import given
from hypothesis.strategies import floats

# Décrit que la fonction prend trois flottants
@given(floats(), floats(), floats())
def test_solve_poly2(a, b, c):
    results = solve_poly2(a, b, c)
    # Test que les résultats sont conformes
    poly = numpy.poly1d([a, b, c])
    for r in results:
        assert pytest.approx(poly(r), 0.0)

Et les résultats ne se font pas attendre.

Falsifying example: test_solve_poly2(a=0.0, b=1.0, c=0.0)
Traceback (most recent call last):
  File "/home/ordinateur/Workspace/pytest/test_number.py", line 35, in test_solve_poly2
    results = solve_poly2(a, b, c)
  File "/home/ordinateur/Workspace/pytest/test_number.py", line 9, in solve_poly2
    results.append((-b + delta**0.5) / (2.0 * a))
ZeroDivisionError: float division by zero

Falsifying example: test_solve_poly2(a=0.0, b=0.0, c=0.0)
Traceback (most recent call last):
  File "/home/ordinateur/Workspace/pytest/test_number.py", line 35, in test_solve_poly2
    results = solve_poly2(a, b, c)
  File "/home/ordinateur/Workspace/pytest/test_number.py", line 12, in solve_poly2
    results.append(-b / (2.0 * a))
ZeroDivisionError: float division by zero

On trouve deux divisions par zéro que nos tests de base auraient pu oublier.

`coverage`

Pour vérifier que les jeux de tests ont une utilité, une bonne méthode est de vérifier leur couverture. La bibliothèque coverage permet cela.

Son utilisation se fait en deux étapes. D’une part l’exécution. Par exemple :

coverage run -m pytest test_number.py

Puis la génération de résultat. Classiquement la couverture en pourcentage de chaque fichier python.

coverage report

Ou plus utile pour améliorer ses tests, la couverture ligne par ligne.

coverage annotate
more test_number.py,cover

> def solve_poly2(a, b, c):
>    """Solve ax^3 + bx^2 + c == 0"""
>    delta = b**2 - 4.0 * a * c
>    results = []
>    if delta > 0:
>        results.append((-b + delta**0.5) / (2.0 * a))
>        results.append((-b - delta**0.5) / (2.0 * a))
>    elif delta == 0:
>        results.append(-b / (2.0 * a))
>    return results

> def pas_couvert():
!    return O + O

`pytest_cov`

Cette extension à pytest ajoute les options de couverture à la commande pytest.

Par exemple, pour générer un rapport du pourcentage de couverture.

pytest test_number.py --cov=.

Ou pour générer les fichiers de couverture.

pytest test_number.py --cov=. --cov-report annotate

Voir aussi

https://wiki.python.org/moin/PythonTestingToolsTaxonomy

Et tes astuces ?

Merci de partager tes recommandations, tes mésaventures, tes bonnes pratiques… :-D

J’ai découvert/appris Python en le pratiquant au bureau à l’arrache, et sans collègue à la fois expert et pédagogue. Du coup, j’ai accumulé plein de mauvaises pratiques que je tente désormais de corriger. Cette dépêche est pour partager mes astuces et faire éviter les mêmes pièges :-)

Je ne suis pas encore un expert Python, alors merci de me corriger gentiment dans les commentaires ;-)

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Python — partie 6 — Pip et Pipx

2021-05-17T08:25:05+02:00

Cette dépêche est la suite d’une série sur Python initiée en septembre 2019. Après un sommeil cryogénique de un an et demi, on repart en forme avec d’autres contenus Python à vous proposer: actualité, bonnes pratiques, astuces, témoignages…

Cette sixième partie explique les inconvénients de pip et présente l’alternative pipx, le tout avec plein d’astuces et de conseils pour bien s’en sortir. 🚀 🐍

Pour rappel, les dépêches précédentes :

Python — partie 1 parlait de la popularité explosive du langage Python
Python — partie 2 évoquait la fin du support de Python 2
Python — partie 3 parlait des différentes façons d’installer Python et des gestionnaires de paquets Python
Python — partie 4 vous présentait py et pyenv pour faciliter la gestion de plusieurs versions de Python en parallèle sur un poste
Python — partie 5 vous faisait découvrir un autre moyen de gérer l’installation en parallèle de différentes versions de Python

lien nᵒ 1 : Python — partie 1 ― Popularité
lien nᵒ 2 : Python — partie 2 ― Python 2
lien nᵒ 3 : Python — partie 3 — Installation de Python et de paquets
lien nᵒ 4 : Python — partie 4 — Py Pyenv
lien nᵒ 5 : Python — partie 5 — Nix (et Guix)
lien nᵒ 6 : Python — partie 7 — Environnements virtuels
lien nᵒ 7 : Python— partie 8 — Pipenv
lien nᵒ 8 : Python ― partie 9 ― Formateur de code, analyse statique
lien nᵒ 9 : Python — partie 10 — Entretiens

Sommaire

La problématique de l’installation des paquets Python
- Le gestionnaire de paquets des distributions GNU/Linux
- Le gestionnaire de paquets pip
La bonne façon d’utiliser pip
- Sous Anaconda ou Miniconda avec conda
Mettre à jour les paquets Python
Environnement Python virtualisé
pipx pour ne plus utiliser pip
Tes astuces ?
Licence

La problématique de l’installation des paquets Python

Le gestionnaire de paquets des distributions GNU/Linux

Les distributions GNU/Linux fournissent des applications et bibliothèques Python. Les intégrateurs de ces paquets font très attention à la cohérence et la compatibilité entre les dépendances communes à toutes ces applications. Les dépendances et applications sont fournies, le plus souvent, dans des paquets séparés. De plus, les intégrateurs prennent en compte certains correctifs, notamment celles concernant les failles de sécurité. Nous avons donc des paquets Python compatibles entre eux, sans faille de sécurité, et dont la mise à jour est gérée automatiquement par le système.

Par contre, ces paquets sont bien souvent dans une seule version, et pas forcément dans la version la plus récente. Un autre inconvénient est le nombre limité de paquets Python disponibles via la distribution GNU/Linux.

C’est pour cela, que nous utilisons pip : pouvoir choisir la version exacte d’un paquet Python, et bien souvent la toute dernière version (voire une pré-version (pre-release)) ou pour installer des paquets Python qui ne sont pas fournis par votre distribution.

Le gestionnaire de paquets `pip`

L’outil pip permet d’installer et de gérer des paquets Python directement en liaison avec le Python Package Index, dépôt qui rend ceux-ci accessibles à tout le monde via l’Internet.

Mais pip n’empêche pas d’installer des dépendances dans des versions incompatibles avec d’autres applications. Et cela nous arrive de temps en temps de casser une application :-( !

La bonne façon d’utiliser `pip`

Généralement, la documentation dit d’installer avec :

pip install nom_paquet

Comme on rencontre un problème de permission, on commence à vouloir bien faire avec :

sudo pip install "nom-du-module-python"    # en root

Ce qui rentre en conflit avec :

sudo apt install "autre-nom-du-meme-module-python"
sudo dnf install "autre-nom-du-meme-module-python"
sudo yum install "autre-nom-du-meme-module-python"

Pour éviter que pip (et pip3) écrase les fichiers installés par apt, sur Debian les deux installations sont séparées :

/usr/lib/python2.7/dist-packages avec apt
/usr/local/lib/python2.7/dist-packages avec pip

Comme Python est très souvent utilisé par des outils de maintenance ou d’administration des machines, cela peut créer des problèmes : installation de versions de certains paquets directement à la place de ceux du système, ou encore installation de certains paquets pour l’utilisateur qui ont la priorité par rapport aux versions installées par le système. Il est très fortement conseillé d’utiliser des environnements virtuels . Il est fortement déconseillé d’installer un paquet via pip dans le cadre d’une commande sudo (le meilleur moyen de casser votre système).

Le pire, c’est de mettre à jour pip avec lui-même, car pip nous le réclame : pip install --upgrade pip et cela a quelquefois comme conséquence de casser pip ! Installer des modules Python devient un bazar si on ne prend pas les bonnes pratiques dès le début.

Cette problématique est très fréquente comme nous pouvons le constater sur le ticket #5599 du projet pip.

Bonnes pratiques :

Ne jamais utiliser sudo pip car la gestion des paquets (et des modules Python) du système est gérée par apt, yum, dnf…
Utiliser pip install --user pour installer des modules pour son besoin personnel sans écraser les modules Python du système ;
Ne pas utiliser pip install (même avec --user)

Les pratiques n°2 et n°3 rentrant en conflit, bien réfléchir avant d’installer un module Python avec pip. Est-ce que le module peut être installé avec apt, yum, dnf ? De quelle version avons-nous besoin ? Et pourquoi pas un environnement Python virtualisé ? Et un conteneur ?…

Bon, revenons à pip, supposons que nous décidions d’appliquer la pratique n°2 et de ne pas écouter la pratique n°3. Nous allons donc installer notre module en précisant toujours l’argument --user :

pip install "nom-du-module-python" --user

Attention, notre pip utilise peut-être Python 2, voici une meilleure ligne de commande :

pip3 install "nom-du-module-python" --user

Attention, nous pourrions avoir plusieurs versions Python 3 installées sur notre machine.
Voici une encore meilleure ligne de commande :

python3 -m pip install "nom-du-module-python" --user

Pour la différence entre pip3 et python3 -m pip lire les détails sur stackoverflow (en anglais). En bref, on est sûr que python3 -m pip utilise la même arborescence d’installation que le script qui est exécuté avec python3 « nom-du-script.py" (ou #!/usr/bin/env python3). C’est d’autant plus recommandé si le $PATH de la machine est tarabiscoté, s’il y a plusieurs installations de Python sur l’ordinateur ou encore que la machine soit sous Windows.

Et si nous voulions préciser l’installation Python avec laquelle nous souhaitons travailler :

/chemin/vers/bin/python3 -m pip install "nom-du-module-python" --user

Attention, si nous avions une ancienne version du module python déjà installée sur notre machine, les commandes pip ci-dessus ne nous permettent pas d’installer la dernière version du module Python :-/

Ajoutons l’argument --upgrade :

python3 -m pip install "nom-du-module-python" --user --upgrade

Nous pouvons aussi changer la barre de progression :

python3 -m pip install "nom-du-module-python" --user --upgrade --progress-bar emoji

Et pour utiliser le module Python fraichement installé :

python3 -m "nom-du-module-python" [options du module]

Oui, cela devient compliqué ! Mais cette façon de faire, avec malheureusement de longues lignes de commande, va nous éviter bien des problèmes.

De plus, même en appliquant les recommandations 2 ou 3, si on installe un paquet pour utilisation avec le Python 3 standard de la machine, ceci peut casser le fonctionnement de certains programmes (le paquet ainsi installé étant prioritaire par rapport à celui du système, s’il y a des incompatibilités… boum). La bonne façon de faire est d'utiliser des environnements virtuels (où l’on peut utiliser directement pip sans risque). C’est une bonne pratique à adopter dès le début afin de s’éviter des problèmes ultérieurs. Cf la suite de la dépêche et la dépêche suivante sur Python où nous vous parlerons plus en détails des environnements virtuels.

Sous Anaconda ou Miniconda avec conda

La société Continuum Analytics qui réalise ces distributions Python fournit des paquets déjà compilés pour de nombreuses bibliothèques Python (et autres langages), principalement dans le domaine des sciences et du calcul mais pas uniquement. Certaines de ces bibliothèques ne sont pas toujours triviales à reconstruire, particulièrement sous Windows. L’adoption d’Anaconda peut être une solution si l’installation de certains paquets échoue avec d'autres distributions.

Attention toutefois avec Anaconda ou Miniconda : ils ont tendance à être très gourmands en espace disque (on arrive assez rapidement à des Gio occupés).

Note : Sous Windows un menu d’application Anaconda Prompt est ajouté dans le groupe de programmes Anaconda. Il permet d’accéder à conda même si celui-ci n’est pas accessible dans les répertoires du PATH.

Conda gère un environnement base, celui par défaut correspondant à son installation de Python, mais peut aussi gérer des environnements supplémentaires avec leurs propres installations de Python et des paquets (avec les versions au choix).

~$ conda activate base
(base) ~$ which python
/home/login/.miniconda3/bin/python
(base) ~$ conda install numpy

…(liste de paquets à installer/mettre à jour)…

Proceed ([y]/n)? y

…(téléchargement puis installation)…

Lorsqu’un paquet n’est pas disponible dans les dépôts de conda, on peut l’installer simplement à partir de PyPI avec pip. Il faut juste prendre soin de lancer pip pour le Python fourni par conda :

(base)~$ conda install osc4py3
…
PackagesNotFoundError: The following packages are not available from current channels:

  - osc4py3
…
(base)~$ python -m pip install osc4py3
(base)~$ python
Python 3.6.9 |Anaconda, Inc.| (default, Jul 30 2019, 19:07:31) 
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import osc4py3
>>>

À noter : certains IDE comme Pyzo donnent directement accès aux commandes conda et pip dans leur fenêtre de shell Python.

Mettre à jour les paquets Python

Avec le gestionnaire de paquets

Les paquets installés avec les gestionnaires habituels sous Linux (apt, yum, dnf…) peuvent être mis à jours simplement avec ces mêmes gestionnaires. Ceux-ci assurent la cohérence des versions installées (et il vaut mieux ne pas interférer avec ce qu’ils installent).

Voir pour chaque gestionnaire de paquets sa documentation pour faire des mises à jour système.

Avec pip

On a vu qu’il était possible avec pip de mettre à jour un paquet particulier avec l'option --upgrade:

/chemin/vers/python -m pip install nom_du_paquet --user --upgrade

Mais il n’y a pas pour le moment de mise à jour automatique simple de l’ensemble des paquets installés avec pip. Celui-ci propose seulement un argument --outdated pour lister les paquets obsolètes. Avec un shell, en l’intégrant dans une expression en ligne de commande, il est toutefois possible de réaliser cette tâche :

/chemin/vers/python -m pip list --user --outdated --format freeze |
  cut -d= -f1 |
  xargs --no-run-if-empty /chemin/vers/python -m pip install --user --upgrade --progress-bar emoji

Sous macOS, il faut retirer l’argument --no-run-if-empty de l’exemple ci-dessus.

Notons que de nombreuses applications système sont codées en Python. Mettre à jour les modules et leurs dépendances même avec l’argument --user peut changer le comportement des applications exécutées par l’utilisateur. Par exemple, si nous utilisons meld en ligne de commande pour comparer deux fichiers, meld pourrait ne plus fonctionner correctement. C’est qu’il fallait respecter la bonne pratique n°3 ! (lire aussi le commentaire de lolop)

Pour l’anecdote, un jour, Oliver décide de mettre à jour ses modules Python dont un module redis qui avait été installé à partir d’un fichier requirements.txt avec une version précise. Sans s’en rendre compte ce module passait de la version 2 à la version 3 avec une incompatibilité dans l’appel des fonctions. Benoît Sibaud a eu un souci similaire avec pyOpenssl en conflit avec la version fournie par le gestionnaire de paquets de la distrib. C’est à ce moment-là que l’on comprend pourquoi pip ne permet pas de mettre à jour tous les modules d’un coup !

Si quelqu’un s’amuse à mettre à jour tous tes modules avec pip, il serait prudent de prendre quand même des précautions comme enregistrer préalablement les versions des modules avant la mise à jour :

python3 -m pip list --user --format freeze > ~/requirements_avant_pip_upgrade.txt

python3 -m pip list --user --outdated --format freeze |
  cut -d= -f1 |
  xargs --no-run-if-empty python3 -m pip install --user --upgrade --progress-bar emoji

python3 -m pip list --user --format freeze > ~/requirements_apres_pip_upgrade.txt

Pour visualiser les changements :

sudo apt install meld

meld ~/requirements_avant_pip_upgrade.txt ~/requirements_apres_pip_upgrade.txt

En cas de problème, revenir aux versions précédentes :

python3 -m pip install --user -r ~/requirements_avant_pip_upgrade.txt

Avec Conda

Pour les paquets fournis via Anaconda ou Miniconda, une simple commande exécutée dans l’environnement conda activé permet d’effectuer les mises à jour dans cet environnement :

(base) ~$ conda update --all
…

Environnement Python virtualisé

Alors, utiliser pip est dangereux ? Oui, sauf dans un environnement Python virtualisé. \o/

L’idée est d’avoir une installation des paquets Python spécifique pour chacun de ses projets, avec une maîtrise des versions et des dépendances, et qui n’interfère pas avec l’installation standard des paquets par le système. Et le tout versionné avec le code source de son projet. Ainsi nous avons une installation équivalente pour les différents développeurs et la production.

Quelques outils pour créer des environnements virtualisés :

python -m venv fait partie des piles fournies avec Python ;
virtualenv est l’ancêtre de venv mais il continue d’évoluer et il est bien plus utilisé que venv (article en français) ;
virtualenvwrapper est une série d’extensions pour virtualenv ;
pipenv est une surcouche agréable au-dessus de virtualenv et de pip ;
conda gère aussi des environnements virtuels, et propose un certain nombre de bibliothèques pré-packagées en supplément à pip ;
pipx crée un environnement virtuel pour chaque programme Python du système, que l’on souhaite protéger d’un cassage accidentel par mise à jour des dépendances.

`pipx` pour ne plus utiliser `pip`

Comme nous le disions, malgré tout le soin apporté à la préparation d’un paquet Python par un développeur et au contrôle soigné de ses dépendances, il arrive que nous cassions de façon incontrôlée des dépendances de paquets Python.

Le cas typique est par exemple un paquet fournissant un utilisateur en ligne de commande, disons supertoto, qui dépend du paquet super en version 1. Par la suite, vous installez un autre utilitaire, supertiti, qui dépend aussi du paquet super mais en version 3. Lors de l’installation de supertiti, le paquet super va être mis à jour vers la version 3, qui malheureusement n’est pas rétro-compatible avec la version 1. Vous venez de casser supertoto.

Pour éviter ce type de problème d’interférence entre les différentes dépendances installées avec pip, l’astuce est d’installer chaque application et ses dépendances dans un environnement isolé.

Et voilà, pipx, une alternative à pip, mais uniquement pour l’installation d’applications Python. Le gestionnaire de paquets pipx n’a pas été conçu pour l’installation de bibliothèques Python (les dépendances).

L’outil pipx installe chaque application dans un environnement virtuel avec venv. Ainsi, plus de conflit entre les différents paquets applicatifs et leurs dépendances respectives, et donc plus besoin de s’embêter avec les environnements virtuels.

Quant à l’outil pip, il peut être relégué à une seule utilisation : installer pipx (un peu comme, sous Windows, le navigateur Explorer/Edge ayant pour seule utilité de télécharger Firefox). On peut aussi installer pipx avec apt/dnf/nix-env/… Les puristes considèrent même que pip est volontairement dissocié de l’installation de Python pour permettre d’utiliser pipx sans jamais devoir passer par pip !

En fait, d’autres outils se basent sur pip comme pipenv, il vaut donc mieux garder un pip fonctionnel sur son ordi. 😁 Les deux outils pip et pipx cohabitent très bien, chacun avec ses avantages. 👍

Installation avec pip :

/usr/bin/python3 -m pip install --user --upgrade pipx

Le plus dur est de prendre l’habitude d’utiliser pipx à la place de pip. Allez, on commence par désinstaller les applications préalablement installées avec pip :

/usr/bin/python3 -m pip uninstall black flake8 pipenv poetry meld

On résinstalle avec pipx :

$ /usr/bin/python3 -m pipx install black
  installed package black 19.3b0, Python 3.7.4
  These apps are now globally available
    - black
    - blackd
done! ✨ 🌟 ✨

Il se souvient bien sûr que l’installation a déjà été faite :

$ /usr/bin/python3 -m pipx install black
'black' already seems to be installed. Not modifying existing installation in '/home/o/.local/pipx/venvs/black'. Pass '--force' to force installation.

D’autres utilitaires sympathiques en ligne de commande, à installer avec pipx :

$ /usr/bin/python3 -m pipx install pipenv
  installed package pipenv 2018.11.26, Python 3.7.4
  These apps are now globally available
    - pipenv
    - pipenv-resolver
done! ✨ 🌟 ✨

$ /usr/bin/python3 -m pipx install poetry
  installed package poetry 0.12.17, Python 3.7.4
  These apps are now globally available
    - poetry
done! ✨ 🌟 ✨

$ /usr/bin/python3 -m pipx install flake8
  installed package flake8 3.7.8, Python 3.7.4
  These apps are now globally available
    - flake8
done! ✨ 🌟 ✨

$ /usr/bin/python3 -m pipx install meld --include-deps
⚠️  File exists at /home/o/.local/bin/futurize and points to /home/o/.local/bin/futurize, not /home/o/.local/pipx/venvs/meld/bin/futurize. Not modifying.
⚠️  File exists at /home/o/.local/bin/pasteurize and points to /home/o/.local/bin/pasteurize, not /home/o/.local/pipx/venvs/meld/bin/pasteurize. Not modifying.
  installed package meld 0.2.3, Python 3.7.4
  These apps are now globally available
    - f2py
    - f2py3
    - f2py3.7
done! ✨ 🌟 ✨

Notons l'option --include-deps nécessaire pour installer meld.

Tes astuces ?

N’hésite pas à partager tes expériences, tes astuces et tes interrogations.

Et un peu d’aide pour la rédaction de cette série est toujours la bienvenue. Les prochaines dépêches parleront de pipenv, d’empaquetage, voire de tout autre sujet que tu pourrais nous amener pour en faire une dépêche. Viens faire un tour dans l’espace de rédaction!

Licence

Cette dépêche est publiée sous licence CC0 (en domaine public dans les pays où cela est possible) pour permettre de la recopier, modifier, réutiliser et republier sans obligation de citer ses auteurs. Sauf dans certains pays, comme la France, dont la loi oblige quand même à citer les auteurs. Au moins, cela montre l’intention des auteurs à autoriser le plagiat.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de Flask 2.0.0

2021-05-14T10:25:05+02:00

Flask est un micro‐cadriciel Web pour Python publié sous licence BSD. Il est conçu pour permettre une prise en main rapide et facile, tout en offrant la possibilité d'évoluer vers des applications complexes. Il a commencé comme une simple « enveloppe » autour de Werkzeug et Jinja et est devenu l'un des cadriciel web Python les plus populaires.

Flask suggère mais n'impose aucune dépendance ou plan de projet. C'est au développeur de choisir les outils et les bibliothèques qu'il souhaite utiliser. Il existe de nombreuses extensions fournies par la communauté qui facilitent l'ajout de nouvelles fonctionnalités.

La version 2 est sortie le 11 mai 2021 soit 3 ans après la version 1.

lien nᵒ 1 : Site officiel
lien nᵒ 2 : Les changements de la version 2.0.0

Les points notables

Flask est maintenant uniquement compatible avec Python 3.6 et plus. Retirer le code de compatibilité pour les versions précédentes de Python a rendu Flask plus rapide et plus facile à maintenir tout en simplifiant les contributions.

Des annotations complètes de type ont été ajoutées au code. Cela rend la vérification des types de votre code plus utile, et permet aux EDI de fournir de meilleures complétions et aides.

Le projet Flask utilise maintenant des outils comme le pre-commit, black, flake8 et pyupgrade pour s'assurer que le code et les nouveaux ajouts de code suivent le même style que l'ensemble du projet.

Prise en charge du mode asynchrone pour les vues et autres rappels tels que les gestionnaires d'erreur, défini avec async def. Les vues en mode synchrone continuent de fonctionner comme avant. Les fonctionnalités ASGI comme les "web sockets" ne sont pas encore prises en charge.

Les modèles de projets peuvent être imbriqués dans d'autres modèles de projets, permettant une approche par couche plus fine pour organiser les applications.

Ajout de décorateurs de chemins pour les méthodes HTTP communes. Par exemple, @app.post("/login") est un raccourci pour @app.route("/login", methods=["POST"]).

En ligne de commande, les erreurs sont plus explicites lorsqu'une application ne peut être chargée. Le serveur de développement fait apparaître les erreurs immédiatement, elles ne sont reportées que lors des rechargements.

Il existe maintenant une fonction Config.from_file qui permet de charger n'importe quel format de fichier de configuration.

La commande flask shell permet maintenant la complétion par tabulation, comme le shell python basique.

Les navigateurs géreront dorénavant le cache des fichiers statiques en fonction du contenu et non plus pendant 12 heures. Cela signifie que des changements sur du contenu statique (comme des styles CSS) seront visibles immédiatement au rechargement sans nécessiter de vider le cache du navigateur.

Démonstration de Flask

Il est nécessaire d'avoir Python (3.6 au minimum) d'installé au préalable.

# Enregistrer ça dans un fichier nommé app.py
from flask import Flask, escape, request

app = Flask(__name__)

@app.route('/')
def hello():
    name = request.args.get("name", "les moules")
    return f'Bonjour, {escape(name)} !'

Installation (ou mise à jour) et exécution

Les commandes précédées d'un $ sont à exécuter dans un terminal dans le même dossier que le fichier précédemment enregistré.

Installation ou mise à jour

$ pip install -U Flask

Exécution de l’exemple de code

$ flask run

Ouvrir un navigateur à l'adresse suivante

http://127.0.0.1:5000/

Arrêter la démonstration

Appuyer sur CTRL+c dans le terminal pour arrêter le serveur

Renommage de la branche par défaut dans le gestionnaire de version de code

Comme d'autres projets (notamment PSF, CPython, Django mais aussi bien d'autres), le projet Flask a renommé sa branche principale dans son dépôt de code de "master" (maître) vers "main" (principal). GitHub simplifie cette transition, voir leur documentation pour les mainteneurs et les utilisateurs.

Si vous avez une copie locale du dépôt Flask, vous devez renommer votre branche principale de master vers main.

$ git branch -m master main
$ git fetch origin
$ git branch -u origin/main main
$ git remote set-head origin -a

Si vous faites une installation depuis l'adresse d'une archive GitHub comme https://github.com/pallets/flask/archive/refs/heads/master.zip, vous devrez renommer ce lien pour utiliser "main".

Utilisation de Flask

Et vous, vous l'utilisez comment Flask ? Où peut-être lui préférez-vous un autre cadriciel web ? Où peut-être trouvez-vous, vous aussi, ce mot "cadriciel" très moche ? Que vous manque t-il dans Flask pour l'utiliser si ce n'est pas déjà le cas ?

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Python — partie 10 — Entretiens

2021-05-12T12:32:03+02:00

Pour cette dépêche, nous donnons la parole à celles et ceux qui pratiquent le langage de programmation Python : des développeuses et développeurs de différents domaines, mais aussi d’autres métiers comme les scientifiques des données (data scientists), les scientifiques de l’apprentissage automatique (machine learning), les analystes quantitatifs (quant)… et bien d’autres…

lien nᵒ 1 : Entretien avec Guido van Rossum (2018)
lien nᵒ 2 : Python — partie 1 ― Popularité
lien nᵒ 3 : Python — partie 2 ― Python 2
lien nᵒ 4 : Python — partie 3 — Installation de Python et de paquets
lien nᵒ 5 : Python — partie 4 — Py Pyenv
lien nᵒ 6 : Python — partie 5 — Nix (et Guix)
lien nᵒ 7 : Python — partie 7 — Environnements virtuels
lien nᵒ 8 : Python— partie 8 — Pipenv
lien nᵒ 9 : Python ― partie 9 ― Formateur de code, analyse statique

Sommaire

Entretien avec tisaac
Entretien avec serge sans paille
Entretien avec Papoteur
Entretien avec liberforce
Entretien avec frague
Entretien avec Jehan
Entretien avec BlueBird75

Entretien avec tisaac

Une petite présentation de ton parcours ?

J’ai un double background, d’une part d’ingénieur en mathématiques appliquées et d’autre part en économie. Je suis sans doute plus économiste qu’ingénieur.

Dans le cadre de mes études et de mes expériences professionnelles, j’ai été amené à étudier/utiliser une série de langages et de logiciels informatique (Java, C++, matlab, Dynare [qqn connaît Dynare ?], Stata, R, Biogeme). Pour les langages informatiques cela s’est presque exclusivement limité aux études.

Aujourd’hui, on pourrait me définir comme modélisateur des transports avec un accent particulier sur les transports publics. En gros, j’interviens à différentes étapes dans l’établissement et l’exploitation de modèles à 4 étapes ou similaires (voir le modèle à 4 étapes spécifique mais bien représentatif de ce genre de modèle). Je suis aussi amené à faire des études plus ad-hoc, pudiquement appelée à dire d’expert. Par ailleurs, j’ai dans un poste précédent assumé un rôle de pricing analyst.

Dans les deux cas (modélisation transport et pricing analyst), il y a pas mal d’analyses de données nécessaires et à force de rencontrer des Data Scientists, j’en viens à penser que je n’en suis pas très éloigné en tout cas des moins pointus.
Comment as-tu commencé à utiliser Python ? Pourquoi ce langage ?

La première fois que j’ai croisé Python c’est durant un truc un peu bizarre, un atelier d’écriture musicale : en gros de la composition par des gens pas forcément musiciens. Les compositions étaient en lien avec le background initial des participants. J’ai donc mis en musique de l’économie. Je ne me souviens plus trop mais en pratique, j’ai utilisé Csound qui faisait intervenir des scripts Python mais en gros cela s’est limité à des boucles for.

Sinon fin de l’année dernière, je suis tombé sur un article de presse au sujet du site de formation en ligne DataCamp orienté Data Sciences. Je devais un peu m’ennuyer ce soir-là et j’ai testé l’un ou l’autre module et en victime du marketing, j’ai payé pour avoir accès à tous les cours. Une fois que j’ai payé, je me suis dit que je devais rentabiliser.

Par ailleurs, en termes de motivation, à ce moment-là, on parlait pas mal de Data Sciences avec un collègue comme étant un truc que nous devions connaître si on voulait rester un peu employable. Finalement, je savais que j’allais avoir bientôt un projet d’estimation de modèle de choix discret un peu atypique et qui allait m’obliger à réécrire des scripts moi-même et pas seulement compter sur Biogeme.

DataCamp offre des formations en R et en Python, pourquoi avoir privilégié le second ? pourriez-vous me demander. Je vois trois raisons. Premièrement, quand on regarde les offres d’emploi pour Data Scientist, Python me semble beaucoup plus souvent mentionné que R. Deuxièmement, le fait que Python soit un langage informatique n’est pas pour me déplaire dans la mesure où je pense parfois à me remettre à la programmation dans mes temps libres. Troisièmement, nous utilisons Visum et ArcGis dans lesquels il y a moyen de faire des choses customisées en écrivant des scripts Python.
Qu’est-ce que tu as trouvé de facile ? As-tu eu des frustrations ?

Ce qui est impressionnant, c’est la puissance de certains paquets et leur nombre. En termes de frustrations, cela reste des scripts informatiques avec des bugs que tu mets parfois pas mal de temps à comprendre. À certains moments, j’aimerais avoir un meilleur background en informatique parce que je sens bien que sur certains trucs, nous ne sommes pas très efficaces.

Ce qui est compliqué, c’est de comprendre les manières d’écrire de telle sorte que le programme soit le plus rapide possible. Dans certains cas, c’est assez simple à comprendre pourquoi une manière est plus efficace qu’une autre mais dans d’autres situations, c’est vachement moins évident et tu n’as en fait rien à comprendre. Tu dois juste retenir que certaines implémentations/paquets sont plus rapides que d’autres. Cet élément fait que Python a une part quand même pas du tout intuitive.
Qu’est-ce que Python t’apporte ? Comment ferais-tu sans ?

Sans Python, j’utiliserais sans doute R et des bases de données SQL.
Quelle a été ta progression dans la maîtrise de Python ?

C’est un peu comme la vision que ma mère a de l’anglais. Elle dit que c’est simple et assez rapide d’arriver à communiquer en anglais mais quasi impossible pour un non-natif de maîtriser toutes les subtilités de la langue. Pour sortir un truc qui fonctionne en Python, c’est vraiment pas compliqué par contre pour bien exploiter toutes ses possibilités, c’est vachement plus long. Malheureusement pour moi, je ne passe pas assez de temps à scripter en Python (j’ai plus un rôle de supervision dans l’équipe), donc je suis et je reste plutôt à un niveau assez basique.
Tes conseils pour les débutants ?

Apprendre un peu l’esprit de Python. La manière d’écrire de manière pythonique. J’ai l’impression que pour un béotien, cela peut aider à faire des trucs plus propres et lisibles.

Ne pas vouloir réinventer la roue. Il y a plein de paquets qui implémentent énormément de chose. La perte de temps de chercher les paquets pertinents pour ton problème est largement compensée par le fait de ne pas devoir écrire (et déboguer) soi-même le script.

Un peu contradictoire avec le conseil précédent, fais attention à ne pas te perdre dans la myriade de paquets existants. Au départ, il est sans doute bon de se concentrer sur un nombre limité de paquets et apprendre à bien les maîtriser. SciPy est dans mon domaine sans doute une porte d’entrée incontournable.

~~Google~~ Internet est ton ami. Il y a plein de documentations en ligne. Sans doute aussi plein de forum de discussion mais jusqu’à présent mes problèmes ont à chaque fois été résolus avec la documentation.

Entretien avec serge sans paille

serge sans paille est un habitué sur LinuxFr.org et également l’auteur du fabuleux logiciel pythran souvent présenté dans nos colonnes qui permet de transpiler (convertir) le Python en C++ pour booster les performances.

Une petite présentation de ton parcours ?

Alors au début je suis allé à droite, puis bas, diagonale bas-droite, droite + punch… je m’égare.

Je suis ce qu’on appelle un dev C++, c’était le cas à l’époque et c’est toujours le cas. À l’époque dans ma boîte à outil script, il n’y avait que /bin/sh.
Comment as-tu commencé à utiliser Python ? Pourquoi ce langage ?

Le hasard :-) Une personne chère à mon cœur s’était inscrite à une formation, elle n’a pas pu y aller, j’y suis allé à sa place… C’était au début de ma thèse donc… vers 2008.
Qu’est-ce que tu as trouvé de facile ? As-tu eu des frustrations ?

Les structures de données de base sont là, le flot de contrôle est simple, la bibliothèque de base est riche… Le typage est implicite, c’est facile et rapide à prendre en main.

L’absence de possibilité d’écrire un vérificateur de type qui soit complet est une grosse frustration. Ou plutôt c’est très frustrant de voir les efforts qui sont mis pour essayer de calquer un système de type partiel sur un langage pas prévu pour.
Qu’est-ce que Python t’apporte ? Comment ferais-tu sans ?

Un magnifique jouet, il y a beaucoup de subtilité dans ce langage qui parait pourtant simple :-) C’est un chouette sujet d’étude. Au quotidien, pour être productif sur des scripts de petite à moyenne taille, c’est mon choix par défaut. Sans lui… je ferais ça en shell, ce qui étale ma faiblesse linguistique :-/
Quelle a été ta progression dans la maîtrise de Python ?
```
compétence
    ^
    |                    ____-----
    |            ____----
    |   ____-----
    |  /
    | /
    |/
    +---------------------------------> temps
```
Maintenant, à travers mon investissement dans le (magnifique, mais vous le savez déjà) projet pythran, j’ai une bonne compréhension de ce qui tourne autour du langage et de ses performances, et de l’interface native. Il m’est arrivé de présenter à PyConFR voire de proposer des patchs mineurs (c’était il y a moins de 18 ans) à CPython.
Qu’est ce qui te plaît le plus ?

L’accessibilité de l’implémentation de référence, cpython (le code source reste appréhendable). La communauté pas trop prise de tête. La diversité de l’écosystème. L’accent mis sur l’outillage. La lib standard.
Tes conseils pour les débutants ?

Comme dans toute activité : pratiquer, essayer, se faire relire, s’intéresser, discuter. L’informatique peut être une activité très sociale !
Que faudrait-il améliorer ?

Il faut savoir s’arrêter, consolider l’existant plutôt que toujours aller de l’avant. Par exemple l’ajout d’un champ type_comment dans de nombreux nœuds de l'AST en 3.8, champs mis par défaut à None, à moins de demander explicitement le traitement des informations de type, donne une impression de cul entre deux chaises.

La gestion des dépendances natives, qui sont au cœur du langage (et oui, Python est quand même un langage de glu à la base), mais reléguées au rang de citoyen de seconde zone du système d’empaquetage, est un vrai problème (et un problème complexe hein).
Quels sujets souhaiterais-tu lire dans les prochaines dépêches ?

Euhhh… Python et performances ? Python et typage ?

Entretien avec Papoteur

Papoteur est un important contributeur du projet Mageia. Il a développé pour Mageia l’application IsoDumper qui permet de faire facilement des clés bootables.

Comment as-tu connu le monde des ordinateurs, en quelle année ?

Ça devait être un Digital Equipement en 1980, quelque chose comme ça.
Quelles études as-tu faites, étaient-ce dans le domaine informatique ?

Des études technologiques, mais pas orientées informatiques. Donc avec un peu de Fortran, IV il me semble.
Autodidacte pour l’essentiel. Avec, à côté, ma femme qui, elle, est diplômée en informatique.
Comment as-tu commencé à utiliser Python ? Pourquoi ce langage ?

J’avais utilisé du Basic et des macros Excel en milieu pro. Je n’avais pas l’intention de devenir un pro de la programmation, donc je voulais me concentrer sur un seul langage, qui soit suffisamment souple d’utilisation et universel. C et C++ me semblaient beaucoup moins abordables. PHP spécialisé sur le Web.

Mon premier programme public est un outil d’écriture d’images ISO sur clé USB, à partir d’un fork. Puis quelques autres utilitaires pour Linux/Mageia.
Qu’est-ce que tu as trouvé de facile ?

L’indentation qui représente l’imbrication facilite l’écriture (pas de contrainte sur les crochets de fermeture oubliés, décalés), même si la coexistence des espaces et des tabulations est source d’énervement. J’apprécie également les formes itératives et la souplesse d’utilisation des variables sans typage.
As-tu eu des frustrations ?

Ce qui m’a le plus contrarié : les formes d’import de mes parties en module selon le contexte de développement ou d’installation.
Qu’est-ce que Python t’apporte ? Comment ferais-tu sans ?

Nul ne peut avoir la prétention d’être irremplaçable. J’aurais regardé du côté de Java, C++, PHP pour ce qui est Web.
Quel est le truc le plus balaise avec Python ?

Faire un backend qui communique en Dbus avec l’application frontale pour exécuter des actions avec droits root.
Est-ce que tu en apprends encore tous les jours ?

Le sujet est tellement vaste qu’il est inépuisable.
Qu’est ce qui te plaît le plus ?

En premier, c’est le langage lui-même, complété par un vaste champ de modules complémentaires. Je ne me souviens pas d’avoir sollicité la communauté, mais par contre consulté nombre de ressources pour trouver des exemples. Open source, évidemment, je n’imagine pas utiliser autre chose.
Quels sujets souhaiterais-tu lire dans les prochaines dépêches ?

Le choix et l’utilisation d’un IDE (ou pas), en particulier pour le débogage.

Entretien avec liberforce

Une petite présentation de ton parcours ?

Mon cousin a 10 ans de plus que moi, et a fait des études d’électronique et informatique, il a eu un Amstrad puis un Amiga 2000, machine assez fascinante. J’ai eu un Amiga 500 à Noël pour mes 12 ans, et même si je l’ai surtout utilisé pour jouer, cela a été mon premier vrai contact avec un shell. Amigaïste un jour, Amigaïste toujours.

Toujours sur les conseils de mon cousin, j’ai découvert les calculatrices HP48 en classe de première, et fait mes premiers pas en programmation sur le bestiau. Je me suis fadé le manuel raccourci, puis le gros de 500 pages… J’ai encore un émulateur HP48 sur mon smartphone quand il s’agit de faire quelques calculs.

J’ai ensuite fait un DUT génie électrique et informatique industrielle option électronique (toujours sur les traces de mon cousin, passé par là 10 ans avant). Big up à l’IUT de Cachan, ce furent deux années extraordinaires. J’ai ensuite suivi ma propre voie en faisant une école d’ingénieur par apprentissage (pour gagner des sous vs en dépenser pour une école privée).
Comment as-tu commencé à utiliser Python ? Pourquoi ce langage ?

Je crois bien que c’est sur les conseils de LinuxFr qui parlait pas mal de ce langage qui montait. J’avais une interface graphique déportée à faire pour le boulot, je m’intéressais à GNOME et GTK+. Le python avait cette réputation de facilité et surtout de lisibilité, on en parlait déjà en bien sur LinuxFr. Alors je me suis naturellement tourné vers pyGTK pour réaliser ce projet. Cela a été mon premier contact concret avec python.

Je tiens à préciser aussi que j’avais (à la même époque ? Quelques années avant ?) gagné un livre sur LinuxFr dans les récompenses aux meilleurs contributeurs, et j’avais choisi un livre sur Python, c’est donc un peu grâce à vous que j’en suis là ;-).
Qu’est-ce que tu as trouvé de facile ? As-tu eu des frustrations ?

Pfiou, ça date. 2006 ? 2007 ? Venant du C/C++, je me rappelle avoir été un désarçonné par le rôle de l’indentation dans le langage. Tous mes fichiers de l’époque sont comme mes fichiers C, indentés avec des tabulations ☺. J’avais aussi un peu effleuré perl et, sans vouloir troller, c’était le jour et la nuit tellement le code python me semblait plus lisible.

Dans les frustrations, en plus de l’indentation, je crois que les args et kwargs étaient un peu obscurs au début, surtout à cause de leur notation à base d’étoiles assez différentes du C.
Qu’est-ce que Python t’apporte ? Comment ferais-tu sans ?

Déjà, il m’apporte des sous ☺. Je fais du python à temps plein depuis un peu plus de 2 ans. Sans ? Je ferais du Rust :-D ! Prochaine étape sans doute, quand j’aurai l’occasion.
Quelle a été ta progression dans la maîtrise de Python ?

Je ne fais pas franchement de truc de haut vol, je reste un (très) modeste développeur loin d’avoir encore appris l’essentiel.

Ma plus grande fierté en python ? Mon premier projet, une interface graphique qui montrait en « temps réel » et de manière très fluide l’état de mon système pour le boulot. J’avais pas mal bossé sur l’amélioration des performances, l’utilisation de cairo, et ça rendait du feu de dieu.

Le truc le plus balaise ? Je vous le dirai quand je l’aurai écrit :-)

Est-ce que j’en apprends tous les jours ? Clairement, développeur c’est un métier sans fin. Et même le python avec sa réputation de facilité a quand même des parties un peu cryptiques. Le typage statique et mypy, les évolutions du langage pour la gestion asynchrone, les subtilités des dataclass… Oui, je pense que j’en apprends encore régulièrement, surtout que le langage change et que je dois avoir en cumulé 3 ans ½ d’expérience.
Qu’est ce qui te plaît le plus ?

La philosophie de Python, le Zen qui m’a permis de mieux comprendre certains concepts que j’avais assimilés empiriquement. « Explicit is better than implicit » est certainement ce qui me sert le plus dans la vie de tous les jours, car beaucoup de gens sont trop implicites dans leur communication. J’essaie de me mettre à la place de quelqu’un qui ne connait pas le sujet quand j’explique des choses, pour m’assurer que mon message reste compréhensible.
Tes conseils pour les débutants ?

De nos jours il y a plein de ressources pour apprendre le python. J’avais utilisé l’application enki d’enki.com sur Android pendant un moment, c’était pas mal pour apprendre de manière progressive un petit peu chaque jour.
Que faudrait-il améliorer ?

Unifier la partie packaging, les solutions pullulant entre les pip-tools, pipenv, poetry et consors.
Quels sujets souhaiterais-tu lire dans les prochaines dépêches ?

Le typage et comment bien l’utiliser est un sujet hautement intéressant pour un langage qui a la réputation d’être typé dynamiquement.

Les stratégies d’analyse statique aussi seraient intéressantes (quelle combinaison d’outils).

Enfin, les stratégies de test, mocking, test doubles (doublures de test en VF) avec pytest par exemple.

En gros, tout ce qui permet de faire du code de qualité afin de pouvoir coder sereinement.

Entretien avec frague

Une petite présentation de ton parcours ?

J'ai touché un ordinateur la première fois en classe de 3ême, c'était un Commodore 64… Çà ne date pas d'hier (83 ?), mais j'ai été mordu.

J'ai alors découvert qu'on pouvait afficher des trucs colorée sur un écran, mais surtout qu'on pouvait demander à l'ordinateur de faire des trucs, via un langage de programmation - du BASIC.

Mon premier ordi perso était un Hector HR-MX, acheté avec la paye de mon premier job d'été. Basic et Forth !

Je n'ai pas fait d'études d'informatique, j'ai travaillé dans le dessin industriel, le meuble… mais l'informatique m'a toujours titillé. J'ai fini par faire une reconversion professionnelle, et je suis maintenant développeur depuis une vingtaine d'année. J'ai fini par valider mon expérience par une Licence Pro Da2I à Lille obtenue en 2004.

J'ai fait un petit peu de C, du VBA, du C#… Je n'ai quasiment fait que du Web.
Comment as tu commencé à utiliser Python ? Pourquoi ce langage ?

Vers 2011, j'avais besoin d'un cadriciel pour faire des applis Web. Mon employeur n'avait pas de préférences quant aux outils / langages de développement. Il est à noter que je travaille dans la fonction publique territoriale.

J'avais alors un petit peu touché à Php, mais je n'était pas emballé - c'était à l'époque php 5, avec ses incohérences criantes.

J'étais à la recherche d'un cadriciel pas trop de haut niveau, mais qui proposait un ORM et une interface d'admin "out of the box". Je sortais d'un truc où le seul endroit où je pouvais taper du code, c'était dans les requêtes SQL, dans un client lourd qui flinguait les indentations à chaque fois que tu sauvegardais la page…

J'ai fait une tour du marché des cadriciels de l'époque, et je suis tombé sur Django.
Qu'est ce que tu as trouvé de facile ? As-tu eu des frustrations ?

Mon premier projet avec Django était un système de calcul de facturation annuelles, basé sur des périodes mensuelles. C'était assez technique, avec des calculs en fenêtres glissantes…

Et bien cà a marche en 3 mois de dev, découvrant en même temps le python (2.7) et Django (1.3). Les deux m'ont séduit !

D'ailleurs je l'ai ré-écrit 1 an plus tard avec l'arrivé des CBV des django 1.4…

Depuis, je continue à faire du dév en python, je fais toujours du Django et un peu de Flask aussi. La richesse de l'écosystème autour de Python me fascine - Il y a toujours quelqu'un qui a fait une lib qui réponds en partie à tes besoins, tu n'a que de la colle à ajouter, et la partie métier, qui est la valeur ajoutée du truc !
Qu'est ce que Python t'apporte ? Comment ferais-tu sans ?

Python est simple à lire et à relire. J'ai des application qui ont été commencé en 2012, et qui tournent et évoluent toujours. Je suis le seul développeur de ma collectivité, je m'occupe de tout "du sol au plafond". J'ai mes utilisateurs à disposition (mes collègues), et ils sont la plupart du temps contents de m'avoir sous la main, que ce soit pour des dévs rapides de 3 / 4 jours (Flask / DB−less) ou pour des projets plus conséquents (Django).
Quelle a été ta progression dans la maîtrise de Python ?

Comme expliqué plus haut, j'ai appris Python "sur le tas". Ma plus grande fierté, c'est que mes applis, grandes ou petites, fonctionnent et rendent service ! J'apprends encore des trucs tous les jours…
Qu'est ce qui te plaît le plus ?

Le langage [x]
La diversité des paquets [x]
La communauté et l'entraide [x]
La gratuité ? L'accès aux sources ? Le partage licence libre [x]

Je coche tout ! J'ai eu l'occasion d'aller à des PyConFR, la qualité et le sympathie des gens rencontrés là-bas était tout bonnement extraordinaire. Et j'apprends tout les jours, ce qui est super !

Tes conseils pour les débutants ?

Plongez ! Il y a plein de tutos sur internet !

Plus sérieusement, pensez à vos algos, le langage de programmation est une façon de les écrire, pas un fin en soi. Mais, par contre Python apporte une vrai lisibilité et une vraie communicabilité de ces algos, je le recommande toujours chaudement aux jeunes gens qui viennent me parler d'informatique.

Sinon, aussi, utiliser un bon débogueur pas-à-pas permet de comprendre finement ce qui se passe quand un script s'exécute, çà a de vraies vertus pédagogiques. Utilisez-en un - çà permet de démystifier la magie opérante…
Que faudrait il améliorer ?

Packaging / environnement virtuels (c'est la grosse question en ce moment autour de python)
setup.cfg vs. pyproject.toml vs. dot files… C'est carrément la jungle, le dossier racine des projets…

Quels sujets souhaiterais tu lire dans les prochaines dépêches ?

Pareil que Liberforce : typing / tests / mocking / qualitay !

Entretien avec Jehan

Une petite présentation de ton parcours ?

Bien que j’ai eu des contacts intermittents avec l’informatique avant, c’est vraiment au lycée qu’un ami me traîne au club informatique régulièrement. C’est aussi vers le milieu du lycée que j’ai eu mon premier ordinateur (Pentium 2?).

Néanmoins même si l’idée du développement me plaît, c’est surtout les jeux vidéos et notamment en réseau que je découvre à ce moment là. Contrairement à beaucoup de développeurs qui ont de la famille ingénieur et ont commencé très tôt, ma famille est dans le milieu artistique et toutes les capacités d’un ordinateur et les possibilités d’interagir avec me passaient un peu à côté.

Pendant une prépa maths, un ami me vante Linux pour la première fois. À cet époque, je le rembarre gentillement, puisque ce système ne m’aurait plus permis de jouer à mes jeux vidéos préférés. Pourtant lorsque je bifurque en licence informatique (directement en troisième année), je découvre que tous les ordinateurs des salles d’informatique de l’université sont sous Linux, je demande donc "Linux" à mon ami : il me fournit un CD d’installation de Mandrake. Comme j’ai toujours le même ordinateur depuis le lycée et que le disque dur est plutôt petit, je supprime Windows et installe Mandrake Linux par dessus (pas de dual boot). Me voici donc pour la première fois sur un OS Libre. Plus jamais je n’ai réinstallé Windows pour mon utilisation perso depuis (presque 20 ans). À l’université, j’ai été forcé d’apprendre à maîtriser cet OS et ses logiciels rapidement, sans même avoir les bases (ligne de commande, scripts, organisation des fichiers… tout était nouveau). Même en développement, en troisième année, on nous apprenait Java et Ada95, tout en supposant qu’on savait le C (je n’en avais jamais fait, j’ai dû apprendre sur le tas en lisant du code). À ce jour, je n’ai jamais eu le moindre cours pour ce langage, mais force est de constater que cela importe peu au final! 🙂

Après cela, j’ai progressivement commencé à m’intéresser au concept de logiciel libre qui m’a vite séduit. L’un des premiers projets majeurs auquel j’ai beaucoup contribué et sur lequel on m’a donné des droits d’écriture puis la maintenance fut l’émulateur de terminal mrxvt que j’utilisais à l’époque car j’avais besoin d’un terminal rapide sur ma machine peu puissante (les terminaux plus répandus étaient tous super lents). J’ai utilisé ce terminal de nombreuses années, surtout qu’à une époque, j’ai vagabondé et ai travaillé pendant des années sur des mini-machines type EeePC où j’avais vraiment besoin d’un terminal réactif. De nos jours, je n’utilise plus ce terminal dont la maintenance est malheureusement abandonnée.

L’autre gros projet qui m’intéressa fut XMPP, au point que j’ai été membre quelques années de la XSF (XMPP Standards Foundation) et qu’on retrouve mon nom dans les sections Acknowledgements des RFCs 6120, 6121 et 6122 (la première vague de mises-à-jour du protocole vers 2011). J’ai cependant mis de côté mon implication sur ce protocole après de nombreuses années à aider à la standardisation, à la communication (j’avais notamment organisé un évènement à la Cité des Sciences pour les 10 ans du protocole; et d’ailleurs si maintenant les habitués de Linuxfr pensent peut-être à moi pour mes commentaires sur GIMP ou le droit d’auteur, il fut un temps où j’étais un de ceux qui parlaient beaucoup de XMPP ici) et avec du développement. Notamment j’avais développé des plug-ins Wordpress. L’un d’eux permettait de se connecter sur son compte Wordpress sans mot de passe, avec un échange de token via XMPP (on recevait une popup sur son client XMPP — potentiellement sur une autre machine — qui nous informait que quelqu’un essayait de se connecter, on pouvait alors accepter ou refuser, et la connexion se faisait automatique sur canal web en fonction du choix sur canal IM). De même ce plug-in permettait de commenter avec validation XMPP (similairement au fait qu’on mette une adresse email pour commenter sur un blog, sauf que le champs XMPP était réellement utilisé pour vérifier que ce n’était pas de l’usurpation d’identité et que l’adresse était utilisée, diminuant ainsi le spam). Personnellement je trouve toujours que c’était une idée cool et j’aurais aimé que ça prenne mais à l’époque les gens n’étaient pas si intéressés par ce type d’usage. Des années plus tard seulement, les concepts d’identification par canal séparé sont devenus classiques (à l’époque, je m’imaginais qu’un jour on pourrait s’identifier sur plein de sites avec son compte XMPP), sauf que ça a divergé par de l’identification GAFAM à la place, comme on le sait 😢. Gros loupé! Enfin bon, toute une époque où j’avais énormément d’idées et de projets sur base de XMPP, mais c’est le passé 🕰️.

Le dernier gros projet pour lequel on me connaît mieux est donc GIMP 🖌️🖼️, sur lequel j’ai commencé à contribuer fin 2012 avec des patchs mineurs, puis majeurs, et de plus en plus… jusqu’à en être devenu mainteneur récemment, grâce au projet ZeMarmot pour lequel on fait du financement participatif depuis quelques années afin d’essayer de vivre de développement sur GIMP!
Comment as tu commencé à utiliser Python ? Pourquoi ce langage ?

J’ai commencé à utiliser Python en 2011, je pense. À l’époque, je travaillais pour une startup à Tokyo (en télé-travail depuis la Corée du Sud) dont la plateforme web utilisait PHP. Comme Python était le langage à la mode, certains ont poussé pour un port du site vers Python (sans bonne raison d’après moi, hormis que le PHP était pas "hype" alors que Python était à la mode), puis le projet a été tué par les managers après 6 mois… 6 mois de travail perdu! C’est à ce moment là que j’ai vraiment appris le Python.

Personnellement je suis technologie-agnostique, c’est à dire que je me fiche un peu des chipoteries sur les langages ou autres guerres de chapelle. J’aime bien Python, c’est un fait. Mais j’ai aussi bien aimé Objective Caml (même si je l’ai trouvé un peu lourd d’usage sur des projets plus poussés), de même que Ada95 (un des langages qui m’a le plus épaté et j’adorais sa rigueur; malheureusement je n’ai pas eu l’occasion d’énormément l’utiliser par la suite)… Même PHP, j’aimais bien (le langage a certes ses petites incohérences et on sent bien qu’il est né de façon un peu bordélique, mais il n’en reste pas moins agréable et j’ai fait des trucs très cool avec. J’avais même écrit un parseur XMPP entièrement en PHP, simpliste mais entièrement fonctionnel, rapidement et en très peu de code, pour mes plug-ins Wordpress/XMPP; ça marchait très bien! 🙂). De nos jours, j’utilise majoritairement du C (comme on peut se l’imaginer pour GIMP), et pas mal de Python sur des projets à côté, ou dès que je veux faire des petits scripts rapides et que bash atteint quelques limites (trop gros scripts bash qui deviennent alors difficiles à lire et maintenir).

En gros, ma logique lorsque je veux automatiser un processus pour moi (ma raison principale de programmer), c’est d’essayer d’abord de faire un script shell POSIX, puis je passe en bash lorsque ça commence à être compliqué de faire du généraliste, et enfin en Python lorsque le code bash devient trop complexe et peu lisible. C’est souvent mon processus de choix de langage pour tout ce que j’écris de zéro pour mes besoins personnels.
Qu’est ce que tu as trouvé de facile ? As-tu eu des frustrations ?

J’aime bien l’indentation significative de Python, ce qui permet de forcer au code propre (dans un projet comme GIMP en C, on est forcé de beaucoup re-demander aux nouveaux contributeurs de bien suivre nos règles de style de code, car la qualité tout comme le style du code sont très importants pour du code maintenable; dans un projet en Python, c’est un peu moins nécessaire d’imposer certaines règles puisqu’elles viennent avec la syntaxe du langage, même si ce n’est pas entièrement vrai et il reste des choix de style à faire).

J’aime aussi bien ses capacités d’introspection, ce qui permet très facilement de créer du code modulable et auto-augmentable, capacités que j’ai utilisé sur plusieurs projets personnels comme professionnels.

J’étais moins fan de fonctionnalités plus avancés de Python, car comme beaucoup de fonctionnalités avancées dans la plupart des langages, elles rendent le code plus dur à lire. Parfois quand je lis du code d’autrui qui aime utiliser les fonctionnalités les plus avancées, j’ai l’impression que certains utilisent ces syntaxes juste parce qu’elles permettent de faire du code plus petit (mais pas plus compréhensible pour autant) ou de montrer sa grande connaissance du langage, et ce aux dépends de la lisibilité et de la maintenabilité. Pour moi, c’est un problème. Mais avec le temps, je suis peut-être moi-même devenu un de ceux qui utilisent des syntaxes avancées un peu absconses au final. Je suis pas sûr. Aussi peut-être que je suis juste paresseux!

Sinon j’aime beaucoup le typage fort (c’est pour que j’adore le langage Ada), même si parfois ça peut aussi rendre certains types de code problématique (notamment les conversions entre type — ce n’est pas forcément un problème conceptuel d’architecture de code ! — peuvent être parfois laborieuses dans certains langages à typage fort). Cela peut rendre un code bien plus robuste et aider à détecter certains types de bugs rapidement, à un niveau plus conceptuel. Donc on peut se demander pourquoi utiliser Python (typiquement le type de langage de script qui cache plein de types d’erreurs de par son typage faible). Néanmoins je ne suis pas sûr qu’il faille changer Python dans un tel sens pour autant. Ce qui fait sa force est aussi sa simplicité pour du code rapide à écrire. Chacun son truc…
Qu’est ce que Python t’apporte ? Comment ferais-tu sans ?

Ça m’apporte juste le fait que ça existe et que je sais l’écrire, donc je m’embête pas. J’utilise. En fait, autant je suis technologie-agnostique, autant je ne suis pas intéressé par apprendre tous les langages informatiques possibles ou bien toutes les fonctionnalités les plus avancées de ces langages. Juste apprendre pour apprendre (attention, c’est très bien d’apprendre pour la beauté du geste, mais au bout d’un moment, on fatigue; perso je préfère apprendre pour arriver à un résultat et parce que ça m’est utile) ne m’intéresse plus autant. Être agnostique signifie juste que je m’en fiche un peu dans quel langage est écrit un logiciel auquel je veux contribuer. Je m’adapte. Bon, bien sûr, si c’est un langage que je connais bien, c’est plus simple, donc je peux me lancer plus facilement, sinon je fais avec, et je lis juste le code lentement pour comprendre ce qu’il fait et comment ce langage fonctionne (on découvre rapidement que ce n’est pas si compliqué).

Par contre, pour mes projets, je me simplifie la vie et prend ce que je connais bien, donc Python. C’est tout! 😛

Et donc sans? J’utiliserais un autre langage, c’est tout!
Quelle a été ta progression dans la maîtrise de Python ?

Rapide au début, puis assez stable pendant des années, je dirais. Je cherche pas forcément à faire les trucs les plus compliqués, comme je disais plus haut, car je privilégie un code lisible et simple. J’apprends bien sûr encore de temps en temps des trucs nouveaux, mais pas tant que cela, et je ne cherche pas particulièrement.

Mon projet le plus important avec Python est probablement Crossroad, mon outil d’aide à la cross-compilation.
Qu’est ce qui te plaît le plus ?

L’API standard est plutôt bien remplie et sa documentation est bien faite. D’ailleurs j’ai un mot clé pour la doc Python qui m’amène automatiquement sur un module dont je veux l’information. Par exemple, si je tape "py3 time" dans ma barre d’URL de Firefox, ça m’emmène à la documentation du module time pour Python 3 (j’ai aussi un mot clé py2 mais comme on peut se l’imaginer, je n’ai plus énormément de raisons de l’utiliser).

J’aime bien aussi le dépôt communautaire Pypi car on y trouve énormément de modules supplémentaires utiles, même si je sais qu’il y a une bonne dose de divergences d’opinion à son sujet, notamment à cause des risques de tels dépôts moins contrôlés. Ces critiques sont d’ailleurs fondées: il ne faut pas installer n’importe quoi. Néanmoins cela n’enlève pas l’utilité du dépôt si on fait attention et si on est conscient des problèmes potentiels. Je fais toujours des recherches préalables à l’installation d’un paquet pip, notamment sur les auteurs, la licence bien sûr, et quelques vérifications du code.

Ensuite j’aime beaucoup le shell interactif ipython, super utile pour tester rapidement du code. C’est le type d’outil qui apporte énormément au confort de développement.
Tes conseils pour les débutants ?

Mes conseils pour les débutants ne dépendent pas du langage: corrigez/contribuez à ce qui vous intéresse. Si vous rencontrez un bug, ou si vous avez besoin d’une fonctionnalité, regardez le code et contribuez un patch. C’est le meilleur moyen d’apprendre et de progresser.

C’est bien simple: les débutants qui viennent nous voir et nous demandent « qu’est-ce que je peux faire si je veux apprendre/contribuer ? », même si on les redirige vers des bugs simples, on ne les revoit quasi jamais. Par contre ceux qui ont rencontré un problème et veulent juste le corriger, ou ont un besoin et veulent le remplir, ceux-ci n’ont pas besoin de demander. Et même s’ils sont débutants, ils progressent toujours le plus vite. Typiquement essayez de développer pour vous, pour vos propres besoins, parce que vous en avez envie. Pas « pour apprendre » ou « pour remplir votre CV » ou « parce que ça fait bien » ou « parce qu’on vous a dit que c’est ce qu’il faut faire », ce qui serait la recette pour un échec sûr. Faire un code qui vous est réellement utile et qui ensuite vous sert au quotidien est tellement plus gratifiant donc ça se fait tout seul ! 😃

Personnellement tous mes développements personnels depuis les ~15 ans que je développe sont juste des choses qui me tenaient à cœur ou des problèmes ou manques que je rencontrais, tout simplement (en plus des contributions sur GIMP et associés, j’ai des petits patchs épars sur des projets aussi divers que Firefox, Blender, mplayer puis mpv, Entangle, Linux Stopmotion, et des dizaines d’autres, notamment des bibliothèques utilisées partout; à chaque fois pour des besoins persos). C’est le meilleur moyen d’apprendre. C’est donc un conseil générique, sans rapport à Python, parce que c’est ce qui a marché pour moi et comme ça que j’ai toujours agi de manière naturelle (sans jamais me forcer à « apprendre coûte que coûte »).
Que faudrait-il améliorer ?

Je ne sais pas trop. C’est pas que Python est parfait, mais je suis plus du genre à m’adapter et à accepter un langage tel qu’il est (tant qu’il n’a pas d’énormes erreurs de conceptions ou de design, bien entendu, mais ce n’est pas le cas de Python).
Quels sujets souhaiterais-tu lire dans les prochaines dépêches ?

Autour de Python, vous voulez dire ? Peu importe, juste des trucs divers intéressants, non? J’apprécie lire les diverses dépêches sur un peu tout et je n’ai pas d’attente en particulier. Ce serait un peu triste si je ne lisais ou ne voulais lire que les trucs que je connais ou qui m’intéressent! Je préfère lire sur des trucs que je connais pas, voire dont je n’ai même pas idée, et donc qui pourraient m’intéresser (mais pour ça faut déjà savoir que ça existe).

Donc étonnez-moi ! Je connais pas tout et suis ouvert à tout. 🤗

Entretien avec BlueBird75

Une petite présentation de ton parcours ?

J’ai découvert les ordinateurs vers la 5e, en 1987, avec un MSX et son langage de programmation intégré : Microsoft Basic. Le fait de pouvoir donner des instructions à un ordinateur et de le voir les exécuter m’a fasciné. Et me fascine encore.

Au Lycée, je suis passé au PC et à Borland Turbo Pascal. En Math Sup, j’ai appris le C et Linux (70 disquettes pour installer une Slackware). Je suis ensuite arrivé dans une école d’ingénieur où les geeks étaient tous fondus de Unix. Si tu parlais pas shell et sed couramment, tu pouvais difficilement intervenir sur le forum de discussion. Ils programmaient presque tous en Perl avec Emacs. J’ai essayé les deux mais ça ne correspondait pas à ma vision de l’informatique : Perl était bien trop enclin à laisser passer des erreurs (langage Write-Only) et Emacs m’a rebuté. J’ai persisté en C et j’ai découvert Vim à la place.

J’ai eu mon diplôme d’ingénieur en télécommunications, mais j’ai rapidement laissé tomber tout ce que j’avais appris en cours pour ne faire que ce que je faisais déjà avant : du développement logiciel ! C’est mon métier et ma passion.
Comment as-tu commencé à utiliser Python ? Pourquoi ce langage ?

Vers les années 2000, Perl était au sommet de sa gloire mais un petit langage commençait à pousser : Python avec sa version 1.5.2 . Puisque Perl m’avait déçu, j’ai voulu voir ce que donnait la concurrence. J’ai immédiatement adoré ce langage qui capturait la bonne manière de programmer : le code est extrêmement lisible, le langage essaie d’être intelligent et quand il doute, il te propose une belle erreur bien claire (par rapport au C++ ou bash que j’utilisais à l’époque par exemple). Et surtout, on est productif rapidement : les structures clés (dictionnaires, listes, tuple, string) sont disponibles immédiatement et de façon très pratiques. Contrairement au C++ où la syntaxe est extrêmement lourde pour obtenir un résultat moins confortable.

Dans mon travail ou pour le logiciel libre, j’ai donc commencé à utiliser discrètement Python.
Qu’est ce que tu as trouvé de facile ? As-tu eu des frustrations ?

Le langage est bien conçu pour le programmeur. A l’époque, n’importe quel développeur C/C++/Java pouvait lire du code Python et le comprendre. Il y a une concision et une clarté qui à mon avis, a permis au langage de décoller. On a un peu perdu cet aspect lisibilité aujourd’hui avec l’ajout de constructions plus complexes dans le langage.

J’ai longtemps été frustré par l’absence de moyen de distribuer facilement du code Python, puis setuptools et pypi.org sont arrivés. Ensuite, programmant sous Windows, j’ai été frustré par la difficulté de livrer une application écrite en Python. Mais py2exe est arrivé et j’ai pu faire des applications pour le bureau de qualité professionnelle, s’intégrant très bien à Windows, sans que personne ne soupçonne que j’utilisais un langage dit de script. J’ai aussi souffert un moment du manque de bibliothèque graphique de qualité, tkinter donnant un look trop passéiste à mon goût aux applications. Puis Phil Thompson a sorti l’excellent binding PyQt et je n’ai plus jamais ralé.

Ces dernières années, j’ai commencé à être frustré par le typage dynamique de Python : dans des grosses applications, on perd vraiment pas mal en compréhension du code et fiabilité. Mais Guido est arrivé avec les annotations de type et mypy pour la vérification et ma vie est redevenue rose.

Avec Python, je suis un développeur comblé. Il rattrape ses faiblesses au fur à mesure des années.
Qu’est ce que Python t’apporte ? Comment ferais-tu sans ?

Mon travail, c’est du développement en C et assembleur pour la carte à puce. Python intervient en tant qu’outil, d’une part pour écrire des tests élaborés, d’autre part, pour résoudre rapidement des problématiques d’automatisation spécifique à notre environnement.

Sans Python, je ferai comme la plupart de mes collègues : j’automatiserai beaucoup moins de tâches et je galèrerai beaucoup plus. Même si en théorie, on pourrait remplacer notre usage de Python par du Visual Basic ou autre, dans les faits, seul les gens qui font du Python semble passer du temps en automatisation. Cela confirme de mon point de vue sa “rentabilité” en terme de temps de développement.
Quelle a été ta progression dans la maîtrise de Python ?

J’aime bien aller au fond des choses, donc assez vite, j’ai acheté un bouquin de référence (merci O'Reilly) pour tout connaitre du langage. C’était plus facile il y a 20 ans, il y avait quand même beaucoup moins de subtilités. J’ai ensuite suivi toutes les évolutions, il n’y a guère que l’API C que je ne suis pas allé voir.

Dans un boulot précédent, l’utilisation de Python couplé à une politique de test intelligente a permis de réduire le temps de test d’un boitier électronique de trois semaines à deux heures. Plus personnes n’a questionné l’utilisation de Python dans mon équipe plutôt que de C#.

Ma plus grande fierté est à venir pour bientôt : je suis en train de pousser mon entreprise à mettre en Open Source un logiciel en Python que j’ai écrit. Une vraie révolution culturelle !
Qu’est ce qui te plaît le plus ?

La lisibilité du code et la facilité à faire des manipulations un peu complexes en quelques lignes. Ça m’arrive souvent de faire des mini-parseur pour des formats textes dans le cadre de tâches d’automatisation. Très vite, je me retrouve avec des listes de dictionnaires de listes de chaînes de caractères et je suis heureux que les structures de bases du langage me permettent ça facilement.

Sur le long terme, j’apprécie la solidité de la communauté Python et le travail de fond qu’a fait Guido Van Rossum pour la construire. Hormis quelques cas où Guido a utilisé son pouvoir de « Dictateur bienveillant », le langage avance avant tout avec un effort communautaire d’entraide. Une licence libre est bien sur essentielle pour ce travail, mais loin d’être suffisant. Faire prospérer une communauté demande un effort important. Par exemple, récemment, un core-développeur du langage a été exclu en raison de sa non coopération et de son agressivité envers ses pairs. C’est un choix difficile à faire, mais essentiel pour garder une communauté saine.

J’apprécie aussi beaucoup les efforts de ces dernières années de la communauté Python pour être plus inclusif, avec un choix délibéré d’avoir
une représentation géographique plus diverses et des initiatives pour faciliter l’accueil de ceux qui ne sont pas des informaticiens masculins blancs.
Tes conseils pour les débutants ?

Je ne suis pas trop en contact avec des débutants, mon public, c’est plutôt les programmeurs intermédiaires ou experts. Mon conseil principal, ne jamais hésiter à refactoriser : renommer pour les rendre le code plus parlant, unifier des traitements, déplacer des traitements dans des fonctions. Tout cela pour un ultime but : rendre du code plus lisible et compréhensible. Une ligne de code va être écrite une fois mais lue des milliers de fois !

Pour du code Python, si le code que vous écrivez fait plus de deux cents lignes, ou est utilisé dans une équipe, ou a une durée de vie de plus d’un mois, ajoutez des annotations de type. Cela le rendra dix fois plus compréhensible. C’est encore mieux si vous vérifier effectivement vos types avec mypy mais rien que le fait de documenter les types rajoute un gros plus en termes de clarté.

Si vous vous lancez dans la vérification de type avec mypy, commencez modeste. Le démarrage est assez chronophage. Et certains cas complexes demandent de lire pas mal de doc pour pouvoir être décrit avec des types précis. Par contre, le gain est vraiment appréciable !

Pour ceux que ça intéresse, j’ai eu la chance d’en parler en conférence à PyParis 2018.
Que faudrait il améliorer ?

Il n’y pas assez de développeurs payés pour travailler sur Python lui-même. Victor Stinner parlait d’un développeur et demi au total payé pour travailler dessus alors que le langage est téléchargé des millions de fois par mois ! On sent bien que les exigences d’un projet de la taille de Python demanderaient plus de temps rémunéré ; ça met une grosse pression sur les volontaires (dont plusieurs ont fait des burnouts). Si votre entreprise dépend de Python, faites des dons à la PSF, cela améliorera la situation.

La gestion de paquets Python va aussi bientôt rencontrer un gros écueil sur la gestion des dépendances. Le nombre de paquets et de dépendances augmente rapidement, et on va tomber de plus en plus souvent sur le cas où une application dépend de deux packages A et B, qui, chacun, dépendent d’une version différente du package C. Des évolutions récentes sur pip permettent de mieux gérer le cas où il existe une version du package C qui résoud toutes les contraintes. Mais à terme, je pense qu’il faudra trouver une solution pour que les package A et B puissent chacun utiliser la version du package C qui leur convient. Ça va pas être trivial !
Quels sujets souhaiterais-tu lire dans les prochaines dépêches ?

J’aime beaucoup les retours d’expérience professionnelle. Surtout si c’est atypique !

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Python — partie 8 — Pipenv

2021-05-11T11:40:41+02:00

Cette dépêche est la suite d’une série sur Python initiée en septembre 2019. Après un sommeil cryogénique de un an et demi, on repart en forme avec d’autre contenu Python à vous proposer: actualité, bonnes pratiques, astuces, témoignages…

Cette huitième partie présente pipenv, un outil pour s’abstraire de pip et virtualenv qui est mis en valeur par la PyPA (Python Packaging Autority). Puis nous finirons la dépêche par un cas pratique avec conteneurisation via Docker, le tout avec plein d’astuces et de conseils pour bien s’en sortir. 🚀 🐍

Pour rappel, les dépêches précédentes :

Python - partie 1 parlait de la popularité explosive du langage Python ;
Python - partie 2 évoquait la fin du support de Python 2 ;
Python - partie 3 parlait des différentes façons d’installer Python et des gestionnaires de paquets Python ;
Python - partie 4 vous présentaient py et pyenv pour faciliter la gestion de plusieurs versions de Python en parallèle sur un poste ;
Python — partie 5 qui dissertait de Nix (et Guix) ;
Python — partie 7 évoquait les environnements virtuels Python et ses alternatives comme la conteneurisation, le tout avec plein d’astuces et de conseils pour bien s’en sortir.

lien nᵒ 1 : Python — partie 1 ― Popularité
lien nᵒ 2 : Python — partie 2 ― Python 2
lien nᵒ 3 : Python — partie 3 — Installation de Python et de paquets
lien nᵒ 4 : Python — partie 4 — Py Pyenv – LinuxFr.org
lien nᵒ 5 : Python — partie 5 — Nix (et Guix)
lien nᵒ 6 : Python — partie 6 — Pip et Pipx
lien nᵒ 7 : Python — partie 7 — Environnements virtuels
lien nᵒ 8 : Python ― partie 9 ― Formateur de code, analyse statique
lien nᵒ 9 : Python — partie 10 — Entretiens

Sommaire

pipenv encapsule pip et virtualenv
Dockeriser Python
- Docker avec pip
- Docker avec pipenv
Remerciements
Licence
Tes astuces ?

`pipenv` encapsule `pip` et `virtualenv`

L’outil pipenv est présenté par l’équipe PyPA (Python Packaging Authority) dans son tutoriel en anglais :
https://packaging.python.org/tutorials/managing-dependencies/

À l’origine, il y a un constat simple : l’ensemble des paquets Python installés sur votre système par votre distribution a bien été testé par cette dernière. Il est délicat d’en rajouter des nouveaux avec pip au niveau système ou même utilisateur car vous risquez de casser cet écosystème bien testé. Si vous avez besoin d’ajouter des paquets, c’est sûrement pour un projet particulier. Donc cela a plus de sens de ne les ajouter que dans ce projet, via un environnement virtuel. Surtout que si vous avez plusieurs projets, ceux-ci n’ont peut-être pas exactement les mêmes besoins.

La conclusion immédiate, c’est que pip et venv s’utilisent conjointement. Cela a un sens de les rassembler. Une autre motivation de Kenneth Reitz pour se lancer dans l’aventure pipenv était son souhait de capturer les dépendances générales d’un projet dans un fichier, et de capturer toutes les dépendances précises en parallèle. Il explique cela mieux dans une présentation sur pipenv que je vous recommande .

Historique

2014, la communauté discute sur le futur format requirements.txt 2.0 ;
2015, nouvelle fonctionnalité demandée pour pip : gérer les environnements virtuels ;
2016, ébauche de pip2 basé sur le format Pipfile, la v 2.0 du format requirements.txt ;
2017, le projet pip2 est renommé pipenv et le dépôt de code source est créé ;
2019, Goldy nous recommande pipenv.

Installation

L’installation de pipenv peut se faire avec le gestionnaire de paquets de la distribution :

$ sudo apt search pipenv
Sorting... Done
Full Text Search... Done
pipenv/disco,disco 11.9.0-1 all
  Python's officially recommended packaging tool

$ sudo apt install pipenv
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  python3-virtualenv python3-virtualenv-clone
The following NEW packages will be installed:
  pipenv python3-virtualenv python3-virtualenv-clone
[...]

L’installation peut aussi se faire avec pip ce qui permet d’avoir une version plus à jour :

$ python3 -m pip install pipenv --user --upgrade --progress-bar emoji
[...]
Successfully installed pipenv-2018.11.26

Dans, mon cas, j’ai installé pipenv avec les deux possibilités, j’ai donc deux exécutables pipenv. Vérifions les versions installées :

$ type -a pipenv
pipenv is /home/oliver/.local/bin/pipenv
pipenv is /usr/bin/pipenv

$ /home/oliver/.local/bin/pipenv --version
pipenv, version 2018.11.26

$ /usr/bin/pipenv --version
pipenv, version 11.9.0

En fait, la version 11.9.0 date du 21 mars 2018, puis, deux mois après, la numérotation des versions est modifiée. La version la plus récente est bien celle installée avec pip.

Rappels :

Installer pipenv avec pip pourrait casser le fonctionnement d’une autre application. Par exemple, la mise à jour de la dépendance virtualenv peut rentrer en conflit avec la version nécessaire à cette autre application. L’installation recommandée est celle avec le gestionnaire de la distribution. Utiliser pip si cela est vraiment nécessaire et que les risques sont maîtrisés.
Ou alors, vous avez lu la dépêche qui parle de pip et pipx et vous installez pipenv avec pipx. Là, vous êtes sûr d’éviter plein de problèmes.

Exemple d’utilisation

Se positionner à la base de son projet et installer les dépendances flask et autopep8 avec pipenv :

$ cd /chemin/vers/mon/projet/chouette

$ pipenv install flask
Creating a virtualenv for this project…
Pipfile: /chemin/vers/mon/projet/chouette/Pipfile
Using /usr/bin/python3 (3.7.3) to create virtualenv…
⠸ Creating virtual environment...Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/tux/.local/share/virtualenvs/chouette-4m-Hw0ap/bin/python3
Also creating executable in /home/tux/.local/share/virtualenvs/chouette-4m-Hw0ap/bin/python
Installing setuptools, pip, wheel...
done.

✔ Successfully created virtual environment! 
Virtualenv location: /home/tux/.local/share/virtualenvs/chouette-4m-Hw0ap
Creating a Pipfile for this project…
Installing flask…
Adding flask to Pipfile's [packages]…
✔ Installation Succeeded 
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
✔ Success! 
Updated Pipfile.lock (662286)!
Installing dependencies from Pipfile.lock (662286)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 6/6 — 00:00:01
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.

$ pipenv install --dev autopep8
Installing autopep8…
Adding autopep8 to Pipfile's [dev-packages]…
✔ Installation Succeeded 
Pipfile.lock (b0a650) out of date, updating to (662286)…
Locking [dev-packages] dependencies…
✔ Success! 
Locking [packages] dependencies…
✔ Success! 
Updated Pipfile.lock (b0a650)!
Installing dependencies from Pipfile.lock (b0a650)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 8/8 — 00:00:01
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.

Nous avons deux nouveaux fichiers :

Pipfile, au format TOML, spécifie les règles générales ;
Pipfile.lock, au format JSON, verrouille (lock) les versions de chacune des dépendances.

$ ls -gG
total 12K
-rw-r--r-- 1 4,5K août  31 15:42 Pipfile.lock
-rw-r--r-- 1  150 août  31 15:42 Pipfile

Le fichier Pipfile sépare les dépendances en deux sections et peut remplacer les fichiers requirements.txt et requirements-dev.txt que nous rencontrons souvent à la base des projets Python. C'est aussi une alternative aux sections install_requires et extras_require du fichier setup.py.

$ head -n 33 Pipfile*
==> Pipfile <==
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]
autopep8 = "*"

[packages]
flask = "*"

[requires]
python_version = "3.7"

==> Pipfile.lock <==
{
    "_meta": {
        "hash": {
            "sha256": "be66bf67d2a9a5d1606be53501e0b029c8c465fc0660151ea0b5c780f7b0a650"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.7"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "click": {
            "hashes": [
                "sha256:2335065e6395b9e67ca716de5f7526736bfa6ceead690adf616d925bdc622b13",
                "sha256:5b94b49521f6456670fdb30cd82a4eca9412788a93fa6dd6df72c94d5a8ff2d7"
            ],
            "version": "==7.0"
        },
        "flask": {
            "hashes": [
                "sha256:13f9f196f330c7c2c5d7a5cf91af894110ca0215ac051b5844701f2bfd934d52",
                "sha256:45eb5a6fd193d6cf7e0cf5d8a5b31f83d5faae0293695626f539a823e93b13f6"
            ],
            "index": "pypi",
            "version": "==1.1.1"
        },

Le fichier Pipfile.lock n’a pas besoin d’être versionné, car pipenv le génère automatiquement à partir du fichier Pipfile. Néanmoins, je recommande de le versionner afin de suivre l’évolution des versions des dépendances et de pouvoir reproduire un même fonctionnement tout au long du cycle : développement, intégration, production…

La commande 'pipenv lock' est l’équivalent de 'pip freeze'. Voir aussi le projet lock-requirements.

Visitons notre environnement virtualisé avec la commande pipenv shell :

$ pipenv shell
Launching subshell in virtual environment…
 . /home/tux/.local/share/virtualenvs/chouette-4m-Hw0ap/bin/activate

$ pip list
Package      Version
------------ -------
autopep8     1.4.4  
Click        7.0    
Flask        1.1.1  
itsdangerous 1.1.0  
Jinja2       2.10.1 
MarkupSafe   1.1.1  
pip          19.2.3 
pycodestyle  2.5.0  
setuptools   41.2.0 
Werkzeug     0.15.5 
wheel        0.33.6

Utiliser [Ctrl] + [D] ou exit pour sortir du pipenv shell.

La commande pipenv run est aussi bien pratique :

$ pipenv run pip list
Package      Version
------------ -------
autopep8     1.4.4  
Click        7.0    
Flask        1.1.1  
itsdangerous 1.1.0  
Jinja2       2.10.1 
MarkupSafe   1.1.1  
pip          19.2.3 
pycodestyle  2.5.0  
setuptools   41.2.0 
Werkzeug     0.15.5 
wheel        0.33.6

Mais pour visualiser ses dépendances, pipenv graph est mieux que pip list :

$ pipenv graph
autopep8==1.4.4
  - pycodestyle [required: >=2.4.0, installed: 2.5.0]
Flask==1.1.1
  - click [required: >=5.1, installed: 7.0]
  - itsdangerous [required: >=0.24, installed: 1.1.0]
  - Jinja2 [required: >=2.10.1, installed: 2.10.1]
    - MarkupSafe [required: >=0.23, installed: 1.1.1]
  - Werkzeug [required: >=0.15, installed: 0.15.5]

Supprimer son environnement virtualisé avec pipenv --rm :

$ pipenv --rm
Removing virtualenv (/home/tux/.local/share/virtualenvs/chouette-4m-Hw0ap)…

Vérifions notre environnement virtualisé :

$ pipenv run pip list
Creating a virtualenv for this project…
Pipfile: /home/tux/chouette/Pipfile
Using /usr/bin/python3.7m (3.7.3) to create virtualenv…
⠼ Creating virtual environment...Already using interpreter /usr/bin/python3.7m
Using base prefix '/usr'
New python executable in /home/tux/.local/share/virtualenvs/chouette-4m-Hw0ap/bin/python3.7m
Also creating executable in /home/tux/.local/share/virtualenvs/chouette-4m-Hw0ap/bin/python
Installing setuptools, pip, wheel...
done.
Running virtualenv with interpreter /usr/bin/python3.7m

✔ Successfully created virtual environment! 
Virtualenv location: /home/tux/.local/share/virtualenvs/chouette-4m-Hw0ap
Package    Version
---------- -------
pip        19.2.3 
setuptools 41.2.0 
wheel      0.33.6

Installons les modules nécessaires en prod avec pipenv install ou pipenv sync :

$ pipenv install
Installing dependencies from Pipfile.lock (b0a650)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 6/6 — 00:00:01
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.

$ pipenv run pip list
Package      Version
------------ -------
Click        7.0    
Flask        1.1.1  
itsdangerous 1.1.0  
Jinja2       2.10.1 
MarkupSafe   1.1.1  
pip          19.2.3 
setuptools   41.2.0 
Werkzeug     0.15.5 
wheel        0.33.6

Enfin, installons les modules nécessaires au développement avec l’option --dev :

$ pipenv install --dev
Installing dependencies from Pipfile.lock (b0a650)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 8/8 — 00:00:02
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.

$ pipenv run pip list
Package      Version
------------ -------
autopep8     1.4.4  
Click        7.0    
Flask        1.1.1  
itsdangerous 1.1.0  
Jinja2       2.10.1 
MarkupSafe   1.1.1  
pip          19.2.3 
pycodestyle  2.5.0  
setuptools   41.2.0 
Werkzeug     0.15.5 
wheel        0.33.6

L’installation de black (formateur de code Python) nécessite d’autoriser les versions bêta car celui-ci n’est livré que en prerelease (cf sa page sur pypi.org):

$ pipenv install --dev --pre black
Installing black…
Adding black to Pipfile's [dev-packages]…
✔ Installation Succeeded 
Pipfile.lock (d00da7) out of date, updating to (b0a650)…
Locking [dev-packages] dependencies…
✔ Success! 
Locking [packages] dependencies…
✔ Success! 
Updated Pipfile.lock (d00da7)!
Installing dependencies from Pipfile.lock (d00da7)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 12/12 — 00:00:02
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.

Sans l’option --dev nous obtenons l’erreur peu explicite "ERROR : Could not find a version that matches black" au milieu d’un tas de logs peu intuitifs. Maintenenant, notre fichier Pipfile contient une section allow_prereleases = true :

$ cat Pipfile
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]
autopep8 = "*"
black = "*"

[packages]
flask = "*"

[requires]
python_version = "3.7"

[pipenv]
allow_prereleases = true

C’est une mauvaise idée d’installer black avec pipenv car cela nous force à activer allow_prereleases = true qui s’applique aussi aux versions utilisées pour l’exécution de l’application. Je recommande plutôt d’installer black avec pip install --user.

Nous avons black, alors désinstallons autopep8 :

$ pipenv uninstall autopep8
Uninstalling autopep8…
Uninstalling autopep8-1.4.4:
  Successfully uninstalled autopep8-1.4.4

Removing autopep8 from Pipfile…
Locking [dev-packages] dependencies…
✔ Success! 
Locking [packages] dependencies…
✔ Success! 
Updated Pipfile.lock (a5c3f0)!

Faisons le ménage, désinstallons les dépendances qui ne sont plus nécessaires :

$ pipenv clean
Uninstalling pycodestyle…

Pipenv est vraiment un outil facile à utiliser et très pratique. Personnellement, j’édite directement le fichier Pipfile qui reste simple, et du coup, je n’utilise plus les commandes pipenv install et pipenv uninstall. En fait, la commande pipenv install est pratique pour ajouter d’une dépendance avec des paramètres compliqués. Dans ce cas, j’applique la ligne de commande de pip install à pipenv install.

Exemple, la documentation dit :

pip install git+ssh://[email protected]/chemin/cool.git#egg=cool

Donc nous remplaçons pip par pipenv :

python3 -m pipenv install git+ssh://[email protected]/chemin/cool.git#egg=cool

Et nous obtenons une nouvelle ligne dans notre fichier Pipfile :

[packages]
cool = {git = "ssh://[email protected]/chemin/cool.git"}

Un autre exemple, avec la documentation qui dit :

pip install prospector[with_everything]

Nous remplaçons pip par pipenv et n’oublions pas l’option --dev :

python3 -m pipenv install --dev prospector[with_everything]

Cela rajoute dans notre fichier Pipfile :

[dev-packages]
prospector = {extras = ["with_everything"],version = "*"}

Index PyPi privé

Souvent, les entreprises ont un index PyPi privé pour permettre de livrer ses propres packages Python en interne. Pour gérer proprement ce cas de figure, voici mes recommandations. Dans le fichier Pipfile, déclarer les deux sources :

[[source]]
source = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[[source]]
source = "private"
url = "https://pypi.monserveur.com/simple"
verify_ssl = true

Si l’index PyPi privé est protégé par un {nom}/{mdp}, chaque utilisateur crée un fichier ~/.netrc avec le minimum de permissions chmod 0600 ~/.netrc et contenant :

machine pypi.monserveur.com
    login    {nom}
    password {mdp}

Pipenv va chercher automatiquement les paquets dans les deux index PyPi. Pour éviter tout conflit, il est possible d’indiquer l’index PyPi concerné :

pipenv install cool --index https://pypi.monserveur.com/simple

Ce qui rajoute dans le fichier Pipfile :

[packages]
cool = {index = "https://pypi.monserveur.com/simple",version = "*"}

😘✨ Merci aux contributrices et contributeurs de pipenv (dont environ 300 personnes listées sur GitHub).

Dockeriser Python

Docker avec `pip`

Prenons un projet Python très simple ayant dateutil comme seule dépendance pour l’exécution (runtime) :

├── mon_app/
│   ├── mon_script.py
│   └── ...
│
├── Dockerfile
│   ║
│   ╚═╡ FROM python:3.7-slim
│     │ COPY requirements.txt /tmp
│     │ RUN pip3 install -r /tmp/requirements.txt
│     │ COPY mon_app /
│     │ CMD ["python3", "/mon_app/mon_script.py"]
│
├── requirements.txt
│   ║
│   ╚═╡ dateutil
└── requirements-dev.txt
    ║
    ╚═╡ black

La première ligne de notre Dockerfile est FROM python:3.7-slim ce qui est un raccourci vers FROM python:3.7.4-slim-buster qui référence un autre Dockerfile sur GitHub. L'image python:3.7-slim correspond à la plus petite image nécessaire pour faire tourner la dernière version Python 3.7 fournie par Debian stable (Buster).

L’ordre des commandes du Dockerfile est important. On commence par ce qui a le moins de probabilité de changer afin de permettre à docker d’utiliser son cache et éviter de perdre du temps à exécuter à nouveau toutes les commandes. Ici, dans notre exemple, changer le contenu de mon_script.py va permettre à docker de réutiliser son cache pour les trois premières lignes du fichier Dockerfile. Si la ligne COPY mon_app /mon_app avait été la toute première, docker aurait alors du ré-exécuter toutes les commandes du Dockerfile pour chaque changement du fichier mon_script.py. Ceci est la raison pour laquelle gérer ses dépendances Python dans le fichier setup.py (install_requires) n’est pas une bonne idée comme expliqué par Itamar Turner-Trauring (en anglais).

Séparer les dépendances pour la production (requirements.txt) est pour le développement (requirements-dev.txt) est une bonne pratique afin d’augmenter la sécurité de notre script (moins de surface d’attaque) et de réduire la taille de notre image Docker.

Le souci de notre fichier requirements.txt est l’absence des versions des dépendances. Nous risquons d’avoir une régression due à une nouvelle version d’une dépendance sans s’en apercevoir. Une solution avec pip est d’utiliser pip-compile pour générer un fichier requirements-lock.txt et de versionner celui-ci avec le code source:

pip-compile requirements.txt > requirements-lock.txt

Docker avec `pipenv`

Migrons notre projet simpliste vers pipenv :

├── mon_app/
│   ├── mon_script.py
│   └── ...
│
├── Dockerfile
│   ║
│   ╚═╡ FROM python:3.7-slim
│     │ RUN pip3 install pipenv
│     │ COPY Pipfile* /tmp
│     │ RUN cd /tmp && pipenv lock --requirements > requirements.txt
│     │ RUN pip3 install -r /tmp/requirements.txt
│     │ RUN pip3 uninstall pipenv
│     │ COPY mon_app /
│     │ CMD ["python3", "/mon_app/mon_script.py"]
│
├── Pipfile
│   ║
│   ╚═╡ [[source]]
│     │ url = "https://pypi.python.org/simple"
│     │ verify_ssl = true
│     │ 
│     │ [packages]
│     │ dateutil = "*"
│     │
│     │ [dev-packages]
│     │ black = "*"
│     │ 
│     │ [requires]
│     │ python_version = "3.7"
│
└── Pipfile.lock

La commande pip ne sait pas installer des modules Python à partir d’un fichier Pipfile, et nous devons installer pipenv. Une demande pour avoir pip install --pipfile Pipfile est en cours de discussion sur GitHub.

Une alternative est de lancer l’application conteneurisée dans l’environnement virtualisé avec ce Dockerfile :

FROM python:3.7-slim
RUN pip3 install pipenv
MKDIR         /mon_projet
COPY Pipfile* /mon_projet
WORKDIR       /mon_projet
RUN pipenv sync
COPY mon_app /mon_projet
CMD ["pipenv", "run", "./mon_app/mon_script.py"]

Remerciements

Merci à tous les contributeurs de cette dépêche, et notamment à Sam & Max, lolop et Ysabeau. Sam m’autorise à copier les articles du site http://sametmax.com 🤩 📄📝 lolop s’est beaucoup investit dans l’organisation de la dépêche précédente et cette dépêche 🤩 🎛🎚 et Ysabeau a initié les illustrations de cette série de dépêches 🤩 🎨🖌.

Extrait du courrier de Sam :

Bonjour Oliver,

Je te donne explicitement l’autorisation de copier, modifier et publier les articles, partiellement, ou en totalité, et de mettre le résultat sous licence CC0. Cette autorisation s’étend à l’écriture de posts inspirés d’articles du blog par Sam ou Max, avec ou sans reprise de contenu, et te laisse libre de piocher dans le texte, les codes et contenus graphiques que nous avons produit, mais ne peut concerner les articles invités ou les images piochées sur le net sur lesquels nous n’avons pas les droits. Les articles invités peuvent néanmoins être repris sous CC-BY, bien entendu.

[…]

Licence

Cette dépêche est publiée sous licence CC0 (sous domaine publique dans les pays où cela est possible) pour permettre de la recopier, modifier, réutiliser et republier sans obligation de citer ses auteurs. Sauf la loi de certains pays, comme la France, qui oblige quand même à citer les auteurs. Au moins, cela montre l’intention des auteurs à autoriser le plagiat.

Tes astuces ?

N’hésite pas à partager tes expériences, tes astuces et tes interrogations.

Et n’oublie pas de nous donner un coup de main pour les autres dépêches sur Python.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Python — partie 5 — Nix (et Guix)

2021-05-09T09:16:00+02:00

Dans les précédentes dépêches, nous avons discuté de la popularité de Python, la fin de la maintenance de Python 2, les différentes variantes de Python, comment les faire cohabiter avec Py et Pipenv…

Dans la continuité de la précédente dépêche, cette dépêche présente une autre approche pour faire cohabiter différentes versions de Python sur un même ordinateur : Nix. 🚀 🐍 💫

lien nᵒ 1 : Python ― partie 1 ― Popularité
lien nᵒ 2 : Python ― partie 2 ― Python 2
lien nᵒ 3 : Python ― partie 3 ― Installation de Python et de paquets
lien nᵒ 4 : Python ― partie 4 ― Py Pyenv
lien nᵒ 5 : Python — partie 7 — Environnements virtuels

Sommaire

Gestionnaires de paquets évolués (Nix, Guix)
- Avec Nix
- Avec Guix
Remerciements
Licence
Tes astuces ?

Gestionnaires de paquets évolués (Nix, Guix)

Nix et Guix sont des gestionnaires de paquets généralistes mais très pratiques pour développer en Python. L’idée de base est d’appliquer les principes de la programmation fonctionnelle à la gestion de paquets. Ainsi, un paquet est vu comme une fonction qui prend l’environnement courant et le code source d’un logiciel, et retourne un nouvel environnement où le nouveau logiciel est disponible. Cette approche simpifie la reproduction, la réutilisation et l’isolation des environnements logiciels créés.

Avec Nix

Créer un environnement Python simple

Nix permet de créer des environnements temporaires. Par exemple, la commande suivante lance l’interpréteur Python en incluant les modules Numpy et Pandas :

$ nix-shell -p 'python3.withPackages(ps: with ps; [ numpy pandas ])' --run python
Python 3.7.5 (default, Oct 14 2019, 23:08:55) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Ici, Python et les modules Numpy et Pandas sont fournis par le dépôt de paquets associé à Nix. Le dépôt standard nixpkgs propose une version de Python 3 et une version de Python 2, avec les modules correspondants. Il est également possible d’utiliser son propre dépôt personnalisé ou de personnaliser spécifiquement quelques paquets du dépôt standard (comme expliqué dans la suite de cette dépêche).

Lorsqu’on travaille sur un projet particulier, on préfère généralement ajouter un fichier shell.nix, qui décrit l’environnement à créer pour le projet :

with import <nixpkgs> {};
(python3.withPackages (ps: with ps; [
  numpy
  pandas
])).env

Une fois ce fichier créé, il suffit de lancer la commande nix-shell pour créer l’environnement correspondant.

$ nix-shell --run python
Python 3.7.5 (default, Oct 14 2019, 23:08:55) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Ce simple fichier shell.nix est déjà très pratique car il permet de définir de façon précise et homogène l’environnement logiciel d’un projet Python. De plus, les dépendances sont mutualisées : si un autre projet nécessite Numpy, ce sont exactement les mêmes fichiers Numpy qui seront utilisés. Enfin, Nix permet de gérer d’autres types de paquets que Python et de personnaliser finement l’environnement, si besoin.

Empaqueter un projet Python, avec toutes ses dépendances

Pour construire un projet Python, on écrit généralement un fichier setup.py. Nix possède une fonction buildPythonPackage pour créer un paquet Nix à partir d’un fichier setup.py. L’intérêt d’utiliser Nix en plus du fichier Python est que l’on peut définir précisément toutes les dépendances (Python ou non) et intégrer notre projet au système Nix (et donc de pouvoir le réutiliser directement dans un autre projet).

Par exemple, imaginons que nous avons un projet Python "myapp" qui utilise le paquet Python Numpy, le paquet système zlib et une bibliothèque interne C++ "mylibcpp" (elle-même empaquetée via Nix). Alors, on peut empaqueter notre projet avec le fichier default.nix suivant :

{ pkgs ? import <nixpkgs> {} }:

let
  mylibcpp = pkgs.callPackage ./mylibcpp/default.nix {};
in
pkgs.python3Packages.buildPythonPackage {
  name = "myapp";
  src = ./.;
  propagatedBuildInputs = [
    pkgs.python3Packages.numpy  # paquet python
    pkgs.zlib                   # paquet non python
    mylibcpp                    # paquet perso
  ];
}

Ce fichier default.nix nous permet de :

lancer un nix-shell et avoir toutes les dépendances nécessaires pour travailler sur notre projet Python;
lancer un nix-build pour construire et exécuter une version finale de notre projet;
lancer un nix-env -i -f . pour installer notre projet sur le système, comme n’importe quel autre paquet de la logithèque de Nix;
réutiliser notre projet dans un autre projet utilisant Nix;
et même, de soumettre notre projet pour une intégration dans la logithèque de Nix.

Modifier l’environnement Python standard

Nix permet de configurer complètement l’environnement logiciel, notamment d’ajouter des paquets Python supplémentaires. Par exemple, si on veut récupérer le paquet Cma sur Pypi et l’intégrer à l’environnement, on peut écrire le fichier shell.nix suivant :

with import <nixpkgs> {};

( let
  cma = python3Packages.buildPythonPackage rec {
    pname = "cma";
    version = "2.7.0";
    src = python3Packages.fetchPypi {
      inherit pname version;
      sha256 = "0nfdq7qznfqcnqwbk04812xiddq8azzbvdj2pa2lvgzxbr00sqzl";
    };
    propagatedBuildInputs = [
      python3Packages.numpy
    ];
    doCheck = false;
  };
  in python3.withPackages (ps: [ cma ])
).env

Il est également possible de redéfinir l’environnement courant. Par exemple, le fichier shell.nix suivant fixe Numpy à la version 1.16.4 et utilise cette version dans le nouvel environnement, notamment pour le paquet Cma, également ajouté.

with import <nixpkgs> {};

(let
  python = let
    packageOverrides = self: super: {

      numpy = self.buildPythonPackage rec {
        pname = "numpy";
        version = "1.16.4";
        src = fetchTarball {
          url = "https://github.com/numpy/numpy/releases/download/v${version}/numpy-${version}.tar.gz";
          sha256 = "1wparj9r5cnh9290s2ikp28yvhx95mainnnlxjgw5p6mppk5zkix";
        };
        doCheck = false;
      };

      cma = self.buildPythonPackage rec {
        pname = "cma";
        version = "2.7.0";
        src = self.fetchPypi {
          inherit pname version;
          sha256 = "0nfdq7qznfqcnqwbk04812xiddq8azzbvdj2pa2lvgzxbr00sqzl";
        };
        propagatedBuildInputs = [
          self.numpy
        ];
        doCheck = false;
      };

    };
  in pkgs.python3.override {
        inherit packageOverrides;
        self = python;
      };

in python.withPackages(ps: [ ps.cma ])).env

Avec Guix

Le gestionnaire de paquets GNU Guix, inspiré de Nix, offre une solution similaire avec la commande guix environment.

Remerciements

Merci à tou⋅te⋅s les contribut⋅rices⋅eurs de cette dépêche, et notamment à Oliver pour l’avoir initiée. 👏 Continuons à participer aux prochaines dépêches. 👍

Licence

Cette dépêche est publiée sous licence CC0 (dans le domaine public dans les pays où c’est possible) pour permettre de la recopier, modifier, réutiliser et republier sans obligation de citer ses auteurs quelle que soit la loi de certains pays comme la France, qui oblige quand même à citer les auteurs. Au moins, cela montre l’intention des auteurs à autoriser le plagiat.

Tes astuces ?

N’hésite pas à partager tes expériences, tes astuces et tes interrogations.

Donne-nous un coup de main pour la rédaction des dépêches à venir.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Python — partie 7 — Environnements virtuels

2021-05-06T13:11:15+02:00

Cette septième dépêche présente les environnements virtuels Python et ses alternatives comme la conteneurisation, le tout avec plein d’astuces et de conseils pour bien s’en sortir. 🚀 🐍

lien nᵒ 1 : Python — partie 1 ― Popularité de Python
lien nᵒ 2 : Python — partie 2 ― Python 2
lien nᵒ 3 : Python ―Partie 3 ― Installation
lien nᵒ 4 : Hors série : Python revient dans la course face à JS & TS
lien nᵒ 5 : Python — partie 4 ― Py Pyenv
lien nᵒ 6 : Python — partie 5 ― Nix (et Guix)
lien nᵒ 7 : Critique des environments virtuels
lien nᵒ 8 : Sam&Max - Les environnements virtuels Python : venv, virtualenv et virtualenvwrapper
lien nᵒ 9 : Sam&Max - pipenv, solution moderne pour remplacer pip et virtualenv
lien nᵒ 10 : Sam&Max - Mieux que Python virtualenvwrapper : pew
lien nᵒ 11 : Python — partie 6 — Pip et Pipx
lien nᵒ 12 : Python— partie 8 — Pipenv
lien nᵒ 13 : Python ― partie 9 ― Formateur de code, analyse statique
lien nᵒ 14 : Python — partie 10 — Entretiens

Sommaire

Environnement Python virtualisé, quésaco
L'ancêtre virtualenv
venv est fourni de base avec Python
virtualenvwrapper pour étendre virtualenv
pew dépasse virtualenvwrapper
conda les gère les aussi
C'est nul les environnements virtuels !
Remerciements
Licence
Tes astuces ?

Environnement Python virtualisé, quésaco

L’idée est d’avoir une installation d'une version de Python et de paquets spécifiques pour chacun de ses projets, avec une maîtrise des versions et des dépendances, et qui n'interfère pas avec l'installation standard des paquets par le système. Et le tout versionné avec le code source de son projet. Ainsi nous avons une installation équivalente pour les différents développeurs et la production.

Quelques outils pour créer des environnements virtuels :

virtualenv, pour Linux / macOS / Windows, est l’ancêtre, continue d’évoluer et toujours très utilisé (article en français) ;
venv est l'intégration de virtualenv dans le cœur de Python, mais il est paradoxalement moins utilisé que son ancêtre virtualenv car venv est plus basique ;
virtualenvwrapper est un ensemble de commandes bien pratiques pour étendre les possibilités de virtualenv tout en le gardant simple d'usage, avec des portages pour Windows (shell cmd et PowerShell) ;
pew est aussi complet et plus simple que virtualenvwrapper ;
pipenv (Linux / macOS / Windows) unifie pip et virtualenv afin de simplifier d'avantage la gestion des environnements virtuels et la gestion des dépendances (versions) et sera abordé dans la prochaine dépêche ;
conda, pour Linux / macOS / Windows, gère aussi des environnements virtuels, et propose un certain nombre de bibliothèques pré-paquagées en supplément à pip.

Nous allons également présenter pyenv pour l'installation de différentes versions de Python et l'activation rapide d'une des différentes installations de Python pour un même projet.

L'ancêtre `virtualenv`

L'outil historique donc, encore très utilisé et qui sert de base pour certaines surcouches. Il est généralement déjà paquagé dans les distributions Linux, et est donc installable par votre gestionnaire de paquets. Sinon, à installer avec pip :

/usr/bin/python3 -m pip install --user --upgrade virtualenv

L'environnement virtuel se crée dans un sous-répertoire, nommé .env-truc dans l'exemple ci-dessous :

$ cd /chemin/vers/le/projet
$ /usr/bin/python3 -m virtualenv .env-truc
  No LICENSE.txt / LICENSE found in source
New python executable in /tmp/truc/.env-truc/bin/python3
Also creating executable in /tmp/truc/.env-truc/bin/python
Installing setuptools, pip, wheel...
done.

ou directement :

/usr/bin/python3 -m virtualenv /chemin/vers/le/projet/.env-truc

Le répertoire .env-truc contient tout ce qui est nécessaire à l’interpréteur Python avec ses commandes et ses bibliothèques. Cet environnement de travail est indépendant des paquets déjà installés sur la machine :

$ $ tree -d -L 4 .env-truc/
.env-truc/
├── bin
├── include
│   └── python3.7m -> /usr/include/python3.7m
├── lib
│   └── python3.7
│       ├── collections -> /usr/lib64/python3.7/collections
│       ├── config-3.7m-x86_64-linux-gnu -> /usr/lib64/python3.7/config-3.7m-x86_64-linux-gnu
│       ├── distutils
│       │   └── __pycache__
│       ├── encodings -> /usr/lib64/python3.7/encodings
│       ├── importlib -> /usr/lib64/python3.7/importlib
│       ├── lib-dynload -> /usr/lib64/python3.7/lib-dynload
│       ├── __pycache__
│       └── site-packages
│           ├── pip
│           ├── pip-19.2.3.dist-info
│           ├── pkg_resources
│           ├── __pycache__
│           ├── setuptools
│           ├── setuptools-41.2.0.dist-info
│           ├── wheel
│           └── wheel-0.33.6.dist-info
└── lib64 -> lib

Pour entrer dans le shell de cet environnement isolé :

Sous GNU/Linux et macOS : source /chemin/vers/le/projet/.env-truc/bin/activate
Sous Windows : C:\\chemin\vers\le\projet\.env\bin-truc\activate\Scripts\activate.bat

Le prompt indique le nom de l'environnement virtuel:

<mon-prompt> $ cd /chemin/vers/le/projet
<mon-prompt> $ source .env-truc/bin/activate
(.env-truc) <mon-prompt> $ type -a python3
python3 is /chemin/vers/le/projet/.env-truc/bin/python3
python3 is /usr/bin/python3

Installer les dépendances avec pip sans affecter les autres installations Python de la machine. Attention à bien utiliser python3 et non pas /bin/usr/python3 :

(.env-truc) <mon-prompt> $ python3 -m pip install requests
Collecting requests
  Downloading https://files.pythonhosted.org/packages/51/bd/23c926cd341ea6b7dd0b2a00aba99ae0f828be89d72b2190f27c11d4b7fb/requests-2.22.0-py2.py3-none-any.whl (57kB)
     |████████████████████████████████| 61kB 5.4MB/s
Collecting urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 (from requests)
  Downloading https://files.pythonhosted.org/packages/e0/da/55f51ea951e1b7c63a579c09dd7db825bb730ec1fe9c0180fc77bfb31448/urllib3-1.25.6-py2.py3-none-any.whl (125kB)
     |████████████████████████████████| 133kB 10.0MB/s
Collecting chardet<3.1.0,>=3.0.2 (from requests)
  Downloading https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl (133kB)
     |████████████████████████████████| 143kB 10.5MB/s
Collecting idna<2.9,>=2.5 (from requests)
  Downloading https://files.pythonhosted.org/packages/14/2c/cd551d81dbe15200be1cf41cd03869a46fe7226e7450af7a6545bfc474c9/idna-2.8-py2.py3-none-any.whl (58kB)
     |████████████████████████████████| 61kB 9.4MB/s
Collecting certifi>=2017.4.17 (from requests)
  Using cached https://files.pythonhosted.org/packages/18/b0/8146a4f8dd402f60744fa380bc73ca47303cccf8b9190fd16a827281eac2/certifi-2019.9.11-py2.py3-none-any.whl
Installing collected packages: urllib3, chardet, idna, certifi, requests
Successfully installed certifi-2019.9.11 chardet-3.0.4 idna-2.8 requests-2.22.0 urllib3-1.25.6

Sortir de l’environnement virtuel :

(.env-truc) <mon-prompt> $ deactivate
<mon-prompt> $

On peut donc créer un environnement virtuel pour chacun des projets, ou même plusieurs environnements virtuels pour un projet : un pour être iso prod, un pour les tests de nouvelles libs…

Cela prend un peu de place, surtout dans .env-truc/lib64/python3.7/site-packages (les dépendances) car pour le reste ce sont des liens symboliques.

$ du -hsc .env-truc/* | sort -h
0       .env-truc/include
0       .env-truc/lib64
76K     .env-truc/bin
16M     .env-truc/lib
16M     total

`venv` est fourni de base avec Python

L'outil venv est similaire à son ancêtre et s'utilise avec la même approche. Création :

<mon-prompt>$ cd /chemin/mon/projet
<mon-prompt>$ /usr/bin/python3 -m venv .env-truc

Activation :

<mon-prompt>$ . .env-truc/bin/activate
(.env-truc) <mon-prompt>$ type -a python3
python3 is /tmp/truc/.env-truc/bin/python3
python3 is /usr/bin/python3

Installation des dépendances :

(.env-truc) <mon-prompt>$ python3 -m pip install requests
Collecting requests
  Using cached https://files.pythonhosted.org/packages/51/bd/23c926cd341ea6b7dd0b2a00aba99ae0f828be89d72b2190f27c11d4b7fb/requests-2.22.0-py2.py3-none-any.whl
Collecting chardet<3.1.0,>=3.0.2 (from requests)
  Using cached https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl
Collecting certifi>=2017.4.17 (from requests)
  Using cached https://files.pythonhosted.org/packages/18/b0/8146a4f8dd402f60744fa380bc73ca47303cccf8b9190fd16a827281eac2/certifi-2019.9.11-py2.py3-none-any.whl
Collecting idna<2.9,>=2.5 (from requests)
  Using cached https://files.pythonhosted.org/packages/14/2c/cd551d81dbe15200be1cf41cd03869a46fe7226e7450af7a6545bfc474c9/idna-2.8-py2.py3-none-any.whl
Collecting urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 (from requests)
  Using cached https://files.pythonhosted.org/packages/e0/da/55f51ea951e1b7c63a579c09dd7db825bb730ec1fe9c0180fc77bfb31448/urllib3-1.25.6-py2.py3-none-any.whl
Installing collected packages: chardet, certifi, idna, urllib3, requests
Successfully installed certifi-2019.9.11 chardet-3.0.4 idna-2.8 requests-2.22.0 urllib3-1.25.6
You are using pip version 19.0.3, however version 19.2.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

Désactivation :

(.env-truc) <mon-prompt>$ deactivate

Espace occupé :

<mon-prompt>$ du -hsc .env-truc/* | sort -h
0       .env-truc/include
0       .env-truc/lib64
4.0K    .env-truc/pyvenv.cfg
36K     .env-truc/bin
14M     .env-truc/lib
14M     total

La documentation officielle de la Python Software Foundation est en français : https://docs.python.org/fr/dev/library/venv.html

`virtualenvwrapper` pour étendre `virtualenv`

Le projet virtualenvwrapper permet de ne plus se soucier du répertoire où se trouvent les environnements virtuels. Ce projet fonctionne et ajoutant des commandes au dessus de la commande virtualenv pour :

organiser les environnements virtuels où que l’on se trouve dans l’arborescence des répertoires ;
simplifier la création/copie/suppression des environnements virtuels ;
passer d’un environnement virtuel à un autre (super utile) ;
compléter la ligne de commande, avec touche [Tab], selon les environnements virtuels disponibles ;
étendre davantage ces commandes avec un système d’extensions (plugins) ;
fournir des crochets (hook) personnalisables.

Installation:

/usr/bin/python3 -m pip install --user --upgrade virtualenvwrapper

Ajouter dans le ~/.bashrc (ou autre fichier de configuration équivalent) :

export WORKON_HOME=~/.virtualenvs
mkdir -p $WORKON_HOME
source ~/.local/bin/virtualenvwrapper.sh

Les commandes suivantes ont le même effet quel que soit le répertoire où l’on se trouve :

mkvirtualenv {nom_env} pour créer un environnement virtuel (avec virtualenv) dans le dossier $WORKON_HOME (~/.virtualenvs) ;
workon {nom_env} pour activer un environnement virtuel ;
rmvirtualenv {nom_env} pour supprimer l’environnement virtuel.

Les options de mkvirtualenv sont les mêmes que pour la commande virtualenv.

`pew` dépasse `virtualenvwrapper`

Installation :

/bin/usr/python -m pip install --user --upgrade pew

Par rapport au projet virtualenvwrapper, le nom des commandes pew (tout comme le nom du projet) sont plus courtes et élégantes. Les commandes pew sont aussi plus nombreuses :

Équivalence	`virtualenvwrapper`	`pew`
`$WORKON_HOME` par défaut	`~/.virtualenvs`	`~/local/share/virtualenvs`
Lister les env	`workon`	`pew ls`
Créer un env	`mkvirtualenv <nom>`	`pew new <nom>`
Supprimer un env	`rmvirtualenv <nom>`	`pew rm <nom>`
Activer un env	`workon <nom>`	`pew workon <nom>`
Aller dans le `site-packages`	`cdsitepackages`	`cd $(pew sitepackages_dir)`
Exécuter sans activer l'env	(aucune)	`pew in <nom> <commande>`
Exécuter dans tous les env	(aucune)	`pew inall <commande>`
Dupliquer un env	(aucune)	`pew cp <nom> <destination>`
Modifier `PYTHONPATH`	(aucune)	`pew add path`
Créer un env temporaire	(aucune)	`pew mktmpenv`
Choisir le dossier par défaut	(aucune)	`pew setproject path`

De plus, pew ne nécessite pas de modifier le .bashrc car pew ouvre un nouveau shell. Donc, la sortie de l'environnement virtuel se fait avec exit ou la combinaison des touches [Ctrl]+[D].

L'inconvénient de pew est de nécessiter l'exécution de l'interpréteur Python pour chaque commande lancée, ce qui alourdit son utilisation et peut rajouter une latence par rapport à virtualenvwrapper, mais cela reste négligeable pour la plupart des machines modernes.

`conda` les gère les aussi

La commande conda d'Anaconda et de Miniconda permet, en plus de la gestion des paquets, de gérer des environnements virtuels Python. On dispose de trois sous-commandes de base :

conda create pour créer un environnement virtuel,
conda activate pour l'utiliser,
conda deactivate pour cesser de l'utiliser

Exemple :

~$ conda create -n testenv1
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /home/login/.miniconda3/envs/testenv1

Proceed ([y]/n)? y
…
~$ conda activate testenv1
(testenv1) ~$

Par défaut l'environnement virtuel reprend la version de Python standard du système. Mais il est possible de spécifier une version de Python à utiliser :

~$ conda create -n testenv2 python=3.7
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /home/login/.miniconda3/envs/testenv2

  added / updated specs:
    - python=3.7

…(plus de choses à installer)…

Proceed ([y]/n)? 

…(téléchargement et installation)…
~$ conda activate testenv2
(testenv2) ~$ which python
/home/login/.miniconda3/envs/testenv2/bin/python
(testenv2) ~$ which pip
/home/login/.miniconda3/envs/testenv2/bin/pip

On remarque qu'une fois l'environnement virtuel activé, la commande pip peut être utilisée directement, de façon saine sans risque de dommages pour votre système.

C'est nul les environnements virtuels !

Des experts Pythons trouvent que les environnements virtuels complexifient inutilement l'utilisation de Python et qu'ils dénaturent la philosophie de simplicité. Ces experts réfléchissent avec la PSF pour trouver une solution plus simple en s'inspirant des écosystèmes Ruby, ~~Node.js~~ Deno, Rust (cargo), Go…

En attendant, pour avoir des espaces de développement indépendants entre ses projets, nous avons des alternatives.

`PYTHONUSERBASE`

La façon la plus basique est d'invoquer pip avec la variable d'environnement PYTHONUSERBASE.

Installer les dépendances :

$ cd /chemin/mon/projet
$ PYTHONUSERBASE=$PWD/.pip-env
$ /usr/bin/python3 -m pip install --user --upgrade requests

Tester son application :

$ cd /chemin/mon/projet
$ PYTHONUSERBASE=$PWD/.pip-env 
$ PYTHONPATH=$PWD 
$ /usr/bin/python3 -m <mon-projet>

ou juste un script :

$ PYTHONUSERBASE=$PWD/.pip-env 
$ /usr/bin/python3 <mon-script.py>

Les variables d'environnement peuvent aussi être mises dans un fichier shell et activées avec source /chemin/mon/projet/activate.sh. Mais bon… on réinvente un peu la roue venv !

export PYTHONUSERBASE=/chemin/mon/projet/.pip-env
export PYTHONPATH=/chemin/mon/projet

Conteneur

Les habitué·e·s des conteneurs, comme Docker, ont tendance à se créer une image avec uniquement la version Python de leur choix, puis de travailler dans un shell de ce conteneur pour y installer les dépendances nécessaires.

De toutes façons, dans ces organisations, les applications sont livrées dans des conteneurs. Pourquoi ne pas utiliser le même environnement qu'en production ?

Attention quand même à bien configurer son image pour conserver ses changements. 😁

Machine Virtuelle

On peut aussi carrément utiliser une machine virtuelle pour isoler un environnement Python. C'est plus lourd qu'un conteneur, mais bon, on faisait comme ça il n'y a pas si longtemps. Sans oublier, que de nombreuses organisations déploient encore leurs applications avec une installation classique. Alors, pourquoi pas utiliser un environnement similaire à celui de la production ?

L'outil vagrant peut aider a scripter la création de sa VM. On peut créer plusieurs VMs sur sa machine (en local) et/ou dans les nuages (cloud)…

AppVM

L'Application Machine Virtuelle (AppVM), concept du système d'exploitation Qubes OS, permet d'isoler chaque application.

Gestionnaire de paquet de nouvelle génération

Le gestionnaire de paquets Nix est fourni avec la commande nix-shell pour activer un shell en spécifiant les dépendances souhaitées.

Le gestionnaire de paquets GNU Guix, inspiré de Nix, offre une solution similaire avec la commande guix environment.

Remerciements

Merci à tous les contributeurs de cette dépêche, et notamment à lolop, Ysabeau et Sam & Max. lolop sʼest beaucoup investi dans la rédaction et lʼorganisation des dépêches 🤩, Ysabeau a initié les illustrations de cette série de dépêches 🤩 🎨 🖌 et Sam m'autorise à copier les articles du site http://sametmax.com 🤩 📄 📝.

Extrait du courrier de Sam :

Bonjour Oliver,

Je te donne explicitement lʼautorisation de copier, modifier et publier les articles, partiellement, ou en totalité, et de mettre le résultat sous licence CC0. Cette autorisation sʼétend à l'écriture de posts inspirés d'articles du blog par Sam ou Max, avec ou sans reprise de contenu, et te laisse libre de piocher dans le texte, les codes et contenus graphiques que nous avons produit, mais ne peut concerner les articles invités ou les images piochées sur le net sur lesquels nous n'avons pas les droits. Les articles invités peuvent néanmoins être repris sous CC-BY, bien entendu.

[…]

Licence

Tes astuces ?

N'hésite pas à partager tes expériences, tes astuces et tes interrogations.

Et n’oublie pas de nous donner un coup de main pour la suite de cette série de dépêches sur Python. Par exemple, Python pour Noël 202X— partie 9 — empaquetage.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

LinuxFr.org : les dépêches de Python

Profileur mémoire MALT 1.6.0 et support de Python

MALT c'est quoi ?

Versions 1.6.0

Avancées

Support de python

Utilisation sur Python

Profilage rapide

Nouvelle interface

Profil statique

Installation

Documentation

Outils similaires pour Python

PyConFR 2025, planning et inscriptions

Kivy : un cadriciel graphique unique en Python

Sommaire

Kivy : boîte à outils graphique multi-plateformes

kv : interface graphique en déclaratif

Les propriétés

Plyer : accéder facilement aux fonctionnalités matérielles de votre appareil

Python For Android : utiliser Python… sur Android

Kivy for iOS : déployez sur les appareils Apple

Pyjnius : utiliser l’API Java Android depuis Python

KivyMD, des widgets Material Design

Quelques limitations

Conclusion

Une note d’histoire

PyConFR 2025, à Lyon du 30 octobre au 2 novembre

PyConFR 2024, planning et inscriptions

Mise à jour de VenC en version 3.2.2

Sommaire

Auto-rafraîchissement lors de la prévisualisation

Assignation d’un thème par défaut

Amélioration des fonctionnalités FTP

Transfert parallèle

Verbosité accrue

Transfert intelligent

Configuration FTP plus fine

Thème par défaut

Nouvelles balises VenC

Accès amélioré à des métadonnées YAML

Accéder à la date de la dernière publication

Taxonomie Avancée

Le mot de la fin

PyConFR 2024, du 31 octobre au 3 novembre à Strasbourg

VenC 3.1.1 | Un nouveau générateur de site statique

Sommaire

Introduction et petit historique

Que permet de faire VenC ?

Faster, smaller, stronger

Travaux et réflexion en cours, le futur de l’application

Le moteur de recherche client-side.

Intégration avec le Fediverse

Sites statiques, deepweb et smolweb

Et le format EPUB ?

Internationalisation des articles

Fonctionnalités de base manquantes

Génération incrémentale et mise en cache.

Auto-rafraîchissement lors de la prévisualisation

Ajout de modules tiers écrit par les utilisateurs eux-mêmes

Le mot de la fin

Ressources du projet

Illustrations

Modules optionnels

L'installation et la distribution de paquets Python (2/4)

Sommaire

Les dangers de pip sous Linux

Pip est un outil de bas niveau

Les environnements virtuels : venv, virtualenv, pipx

L’invocation d’un build backend : build

Le transfert sur PyPI : twine

La configuration d’un projet : le fichier pyproject.toml

Les build backends pour code Python pur

La gestion des versions de Python : pyenv

Un outil de test et d’automatisation : tox

Interlude : vous avez dit lock file?

Un gestionnaire de lock file : pip-tools

Les outils « tout-en-un »

La création d’exécutables indépendants et installeurs : PyInstaller, cx_freeze, briefcase, PyOxidizer (etc.)

Conda, un univers parallèle

Kivy : un cadriciel graphique unique en Python

Kivy : boîte à outils graphique multi-plateformes

kv : interface graphique en déclaratif

Plyer : accéder facilement aux fonctionnalités matérielles de votre appareil

Python For Android : utiliser Python… sur Android

La configuration d’un projet : le fichier `pyproject.toml`

La montée en puissance de `pip` et PyPI

Le développement d’un écosystème alternatif, `conda` et Anaconda

PEP 623 − Préparation de la suppression de `wstr` dans `PyUnicodeObject`

PEP 618 − Ajout d’une vérification optionnelle des longueurs dans `zip`