Nous étions à PyConFR 2015 avec quelques personnes de l'agence toulousaine de Logilab.
Nous avons présenté 3 sujets (annoncés ici), les conférences ont été enregistrées, elles devraient être disponibles bientôt (update les vidéos ont été publiés) :
Nous avons vu de nombreuses conférences et discuté python pendant les
pauses, voici quelques concepts ou pointeurs qui ont retenu notre
attention.
Le travail qu'effectue Fedora sur son bus de message au niveau de
l'infrastructure (fedmsg)
est fort intéressant, nous faisons des choses similaires avec le bus
d’événements de Salt sur notre
infrastructure.
Toujours chez Fedora, nous allons jeter un œil sur faitout qui permet de récupérer une
base de données Postgresql temporaire à utiliser dans les tests
unitaires ou l'intégration continue.
Nous utilisons déjà tox,
pour un certain nombre de projets, mais cette présentation nous a motivés pour
approfondir quelques pistes : comme detox
pour tester les environnements en parallèle. tox permet de lancer les tests unittaires (mais
aussi construire la documentation) dans des environnements virtualenv, permettant ainsi de
tester une grille de configurations (différentes versions de python, ou de dépendances).
Guix est un gestionnaire de paquets et une distribution, c'est un projet
prometteur, même si nous restons très attachés à Debian. Guix s'inspire
du travail effectué par NixOS (dont une
présentation avait été faite lors d'un meetup salt). Un peu avant-gardiste,
mais probablement utile à terme.
Bandit,
est un outil d'analyse statique qui se focalise sur la sécurité. Il est
capable d'analyser du code Python pour détecter les failles de sécurité les
plus courantes: SQL injection, XSS, attaque par symlink. Bandit ne fait pas tout
(il ne détecte pas le code qui n'existe pas mais qui devrait y être), mais c'est
un outil précieux pour automatiser les tests de sécurité et gagner du temps.
Bien sûr, la meilleure école pour se former reste de lire les patchs qui
corrigent les failles de sécurité et de se faire auditer par des experts. L'analyse de code
est un sujet qui nous intéresse, car pylint est né à Logilab et
nous travaillons encore sur ces sujets avec astroid (ancien logilab-astng)
et safe-python.
Scapy permet de recevoir, d'envoyer et
de manipuler des paquets réseau. Il supporte de nombreux
protocoles, et peut être utilisé notamment à des fins d'audit.
Deux conférences consécutives concernant SQLAlchemy
et GeoAlchemy, bien que restant à un niveau de
généralités, ont été très instructives. On peut en retenir que, malgré la refonte de l'API avec la
version 1.0, les fonctionnalités les plus utiles de SQLAlchemy restent cachées (declarative,
back_populate), et les bonnes pratiques sont très mal connues, car mal documentées. La
présentation en donnait quelques unes comme "ne jamais faire de requête dans une boucle", ou
encore "dans un join, il vaut mieux expliciter toutes les tables". Côté GeoAlchemy, la présentation
voulait montrer qu'il est très simple de manipuler des données géométriques avec cet outil
développé par la société franco-suisse camp2camp.
Comment optimiser le code Python de Mercurial pour
qu'il assure des performances suffisantes, quels sont les pièges à éviter ?
C'était l'objet de la conférence de Pierre-Yves David, qui a débuté le développement de
evolve en 2011 quand
il travaillait à Logilab et que nous cherchions à améliorer nos processus de revue de code.
Côté astuces, on a retenu entre autres
l'utilisation des slots, un mécanisme
d'import paresseux (présent en standard dans Python 3), la désactivation ponctuelle du ramasse-miettes
ou encore le pré-chargement d'attributs ou de fonctions hors des boucles.
Nous avons pu assister à une présentation très intéressante sur la tabulation avec Python. La
tabulation c'est la mémoïsation poussée à l’extrême: enregistrer tous les résultats d'une fonction
pour toutes les valeurs possibles des paramètres. Dingue, non ? La présentation montrait que,
moyennant la prise en compte de contraintes techniques (limiter le domaine des paramètres,
optimiser le tableau des résultats en le découpant), cela était tout à fait possible, et apportait un
gain de temps réel. Mais en fait l’intérêt ne réside pas vraiment dans le fait de mettre en cache des résultats
pour gagner en temps de calcul ; non, il s'agit plutôt de masquer le code d'une fonction.
Au lieu de fournir à l'utilisateur une version compilée qui risque de faire l'objet de rétro-ingénierie, on lui fournit
le tableau des valeurs possibles en entrée et le tableau des résultats correspondants en sortie. La probabilité
de retrouver l'algorithme est alors moindre, surtout pour des fonctions de type hachage que
certaines sociétés tiennent à garder secrètes.
Hospital avec ses healthchecks en
production pourrait être un bon candidat pour nos applications
CubicWeb qui sont déjà branchées sur du statsd pour les métriques métier et
sentry pour la collecte d'anomalies. Le projet qui n'en est encore qu'à ses débuts mais
contient certaines idées intéressantes. L'objectif est de pouvoir tester les déploiements
d'une application. Les outils qui existent ne permettent d'avoir qu'une partie de l'objectif:
- les tests automatiques, même fonctionnels, testent l'application hors de son
environnement final. Ou alors il peut être long de les lancer une fois l'application déployée ;
- la supervision permet de détecter les problèmes mais l'application est vue comme une
boîte noire: savoir qu'il y a une erreur 500 ne permet pas de dire si c'est la base de
données qui est HS ou s'il n'y a plus d'espace disque ;
- les logs permettent de voir quel est le problème réel, mais trop tard.
Hospital est un framework qui permet:
- d’écrire des tests avec des assertions comme pour les tests automatiques ;
- de faire des assertions sur l'application vue de l’intérieur comme une boîte blanche. Il est
ainsi possible de tester la connectivité à la base de données ;
- et de collaborer avec les outils existants comme les outils de supervision. Il existe par
exemple un exécutable en ligne de commande qu'un outil de supervision est capable de
lancer.
AnyBlok a retenu notre
attention car ses concepts ressemblent à ceux de CubicWeb et les deux projets pourraient s'enrichir mutuellement.
CubicWeb et Pyramid (la vidéo) a été présenté
par Christophe de Vienne de Unlish, qui a beaucoup oeuvré pour ce
rapprochement. C'est maintenant ce qui est utilisé à Logilab.
Pythran est un traducteur de code Python en C++, qui permet de construire
un module d'extension optimisé à partir d'un code pur Python enrichi de quelques annotations.
Il est destiné à un usage scientifique et offre notamment un support partiel de numpy.
Il a retenu notre attention et pourrait représenter une alternative intéressante à cython pour
certains de nos développements. Son auteur est un partisan de la programmation déclarative: on doit écrire ce
que l'on veut obtenir et non pas comment l'obtenir. C'est au compilateur ou à un traducteur de code comme
pythran de trouver alors la meilleure façon d'obtenir le résultat décrit. Une partie des améliorations de Pythran
est aujourd'hui financée via Logilab grâce au projet OpenDreamKit.
Merci aux organisateurs et à l'EISTI de Pau pour l’accueil. À l'année
prochaine pour une nouvelle édition de pyconfr.
Article rédigé à 3 mains par Yann Voté, Laura Médioni et Arthur Lutz