#pyconfr

Les 23 et 24 septembre derniers, j’étais à Toulouse pour l’édition 2017 de PyCon FR. Le programme était riche, avec trois « tracks » en parallèle, sans compter les « sprints » et les ateliers. Je partage ici quelques notes sur les présentations auxquelles j’ai pu assister.

Tests

Le samedi après-midi, plusieurs présentations se sont succédées autour de la thématique des tests, dans une sorte de mini « track ».

Vincent Maillol nous a d’abord présenté une approche intéressante qu’ils utilisent pour les tests fonctionnels de leur API / application web. L’outil (cricri) permet d’exprimer des scénarios de test en déclarant les différentes parties et les contraintes associées (la partie A est optionnelle, mais doit s’exécuter avant la partie B). Il va générer automatiquement les tests correspondant aux différentes combinaisons.

L’outil s’intègre au test runner standard de Python, mais malheureusement pas à Pytest.

J’y ai retrouvé des analogies mais aussi des différences avec l’approche BDD (voir par exemple pytest-bdd pour une implémentation en Python) :

dans les deux cas on va pouvoir découper ses scénarios en « steps » réutilisables

dans l’approche BDD, on va plutôt lister explicitement tous les scénarios, ce qui a une valeur en terme de documentation et de communication avec l’équipe produit, mais qui peut introduire une certaine redondance ; l’approche générative est plus concise, mais ça peut devenir plus difficile de savoir quels scénarios sont effectivement pris en compte

dans l’approche BDD, on va plutôt écrire les scénarios dans un DSL comme Gherkin, toujours dans le but d’être lisible par des non-développeurs, mais ça rajoute un niveau d’indirection et donc de lourdeur dans l’écriture des tests (personnellement je préfère écrire un test fonctionnel directement en Python qu’en Gherkin)

Une piste de réflexion : utiliser Hypothesis pour générer automatiquement des séquences d’opérations sur une application ou une API, chacune étant ensuite définie par un « step », de manière à valider des invariants (par exemple : en aucun cas deux utilisateurs ne peuvent réserver un même logement à la même date).

J’ai apprécié ensuite la présentation de Boris Feld et Pierre-Yves David sur les tests de performance. Ils ont bien présenté l’intérêt de considérer la performance comme une fonctionnalité du logiciel, et de suivre son évolution avec le temps via une suite de tests de performances automatisés.

Ils ont exposé toute une série de facteurs à prendre en compte pour limiter la variabilité des résultats, au niveau du matériel, du noyau et des outils. Difficile d’avoir un environnement contrôlé dans le cloud, donc pour leurs besoins ils ont mis en place une machine physique dédiée.

Deux outils à retenir :

perf : prépare le système, exécute les benchmarks, enregistre les données...

asv (Air Speed Velocity) : un peu le Jenkins des tests de performance. Il sait lancer automatiquement la suite de tests de performance à chaque commit, stocker les résultats, les afficher sous forme de jolis graphe, et détecter les variations significatives.

Enfin, j'avais moi-même une présentation de quelques techniques de test avancées en Python (les diapos et les exemples). Merci à tous ceux qui m'ont fait des retours, j'ai apprécié vos compliments comme vos suggestions d'amélioration. J'ai noté notamment de regarder libfaketime, une alternative à freezegun avec de meilleures performances, et d'aborder les manières d'intégrer tox et Travis CI.

Devops

Côté devops, la présentation de Gaël Pasgrimaud montrait que malgré l’abondance d’outils d’orchestration et de gestion de configuration, certains cas d’utilisation restent mal couverts. Leur besoin : exécuter des tâches impératives sur un grand nombre de machines hébergées (plusieurs dizaines ou centaines) sur lesquelles ils ne peuvent pas forcément installer d’agent (connexion exclusivement par SSH). Ils utilisent habituellement Ansible, mais les administrateurs sytème n’étaient pas satisfaits de ses performances dans ce scénario.

Dans un contexte où l’on peut installer un agent, je pense que Salt serait une bonne solution (utilisé par exemple chez LinkedIn pour gérer plusieurs dizaines de milliers de serveurs). Et avec un plus petit nombre de machines, quelque chose de plus simple comme Fabric (+ fabtools !) fonctionne de manière satisfaisante. Mais pour commander efficacement 300 machines par SSH, aucune solution existante ne semblait convenir.

Ils ont donc développé un outil maison (nuka) basé sur Python 3, utilisant asyncio pour gérer les multiples connexions SSH concurrentes.

La discussion sur les goulets d’étranglement (bottlenecks) rencontrés a été intéressante : la principale limite aux performances (au delà de la qualité du réseau) était la connexion locale à l’agent SSH pour l’authentification par clé.

Un peu plus tard, la présentation de Philippe Pépiot a porté sur testinfra, une bibliothèque qui permet d'écrire des tests qui décrivent l'état souhaité d'un serveur, indépendamment de l'outil de gestion de configuration utilisé (Chef, Puppet, Salt, Ansible...). Je suis fan de cette approche, et ça me semble une super alternative à serverspec (là aussi, je préfère écrire mes tests avec Python et pytest qu'avec un DSL Ruby).

Scaling et parallélisme

La présentation de Julien Danjou était un excellent état de l’art sur les approches et les outils pour le parallélisme et les systèmes distribués en Python : multi-thread, multi-process, queues...

J'ai noté plusieurs bibliothèques et outils intéressants à regarder :

cachetools : lorsque le functools.lru_cache de la bibliothèque standard ne suffit pas

cotyledon : pour gérer des processus à longue durée de vie (services / démons)

futurist : extensions à l'excellent module concurrent.futures de la bibliothèque standard

tenacity : un décorateur @retry très paramétrable pour réessayer automatiquement les accès à des services qui peuvent être indisponibles

fasteners : une bibliothèque qui forunit plusieurs implémentations de verrous (locks)

Unicode et alphabets

Boris Feld a refait sa très bonne présentation qui démystifie les chaînes de caractères, les octets, l’unicode et toutes leurs feintes en Python 2 et 3.

Ensuite Guillaume Ayoub à enchaîné avec une présentation riche, agréable, analogique et participative, qui nous a emmené des origines de l’écriture aux Emoji en passant par l’explication des différences entre crénage (kerning), anti-crénelage (anti-aliasing) et hinting en typographie numérique.

Et le reste

Impossible de voir toutes les présentations intéressantes dans une telle conférence, donc j’ai notamment loupé :

la présentation de Stéphane Angel et Joachim Jablon sur les bonnes pratiques de packaging

la présentation de Xavier Ordoquy sur les fausses bonnes idées dans les API REST

la présentation de Frank Rousseau sur l’utilisation de Python par les professionnels de l’animation 3D

et plein d'autres qui étaient sûrement très bien aussi...

Heureusement les conférences ont été filmées, donc une séance de rattrapage sera possible dès qu'elles seront en ligne !