Python a le vent en poupe

L'usage de Python a augmenté de 45% depuis le printemps dernier. La raison: Le Google's App Engine qui utilise comme chacun sait Python a glané un tas de développeurs non Python. Bref merci qui , merci Google !!

Et on peut se poser maintenant la question : est-ce que perl est mort aujourd'hui ?

la réponse se trouve là : http://isperldeadyet.com/

Funkload pour les impatients

Funkload est un outil de stress. Il s'utilise avec buildout. Il y a une recette collective.recipe.funkload qui permet d'initialiser via buildout un test funkload. collective.coreloadtests (http://pypi.python.org/pypi/collective.coreloadtests/0.1) définit lui trois tests de base pour Plone. Un de création de contenu, un de lecture et un d'écriture intensive. collective.loadtesting (https://svn.plone.org/svn/collective/collective.loadtesting/trunk/README.txt) fournit lui aussi des tests de base pour funkload. De plus il fournit un enregistreur de test.

Pour aller plus loin:

• funkload et builbot : http://toutpt.wordpress.com/2009/11/02/my-sprint-report-funkload-and-buildbot-ploneconf2009/
• tutorial funkload : http://blog.redturtle.it/redturtle-blog/how-to-write-funkload-test-in-few-minutes
• Une étude sur l'amélioration des performances de Plone (très intéressant) qui utilise funkload : http://www.slideshare.net/amleczko/plone-tuneup-challenges

Une étude comparative de 6 frameworks en terme de performance.

• http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/

L'histoire du packaging en Python

Python depuis la fin des années 90 a cherché des solutions de packaging professionnel pour ses applications et ses bibliothèques. Martijn Faassen a été l'un de ces contributeurs historiques et nous livre dans cette article l'histoire, le fil des outils qui se sont succédés pour avoir les outils qu'on connaît aujourd'hui. C'est en comprenant ce qui a été fait hier qu'on comprend ce qu'on a aujourd'hui.

Bref les étapes du packaging de Python commence par :

• Distutils

Lancé fin 1998 , Greg Ward (http://www.python.org/~guido/confpix/gward.jpg) dans le cadre d'un groupe de discussion sur le sujet du packagement crée Distutils. Distutils permet de structurer votre projet avec un setup.py. Grâce à ce fichier il est possible de compiler, installer , fabriquer des archives pour votre projet. Distutils est ajouté à la bibliothèque standard du python 1.6 sorti en 2000.

• Metadata

A la suite de Distutils, la fabrique de paquet python est maintenant possible. Par contre il n'y avait pas d'index centralisé et de façon normalisé pour les décrire. Andrew Kuchling a contribué sur ce sujet en décrivant et implémentant le PEP 241 puis sur son évolution , la PEP 314. Apparaît alors un fichier nommé PKG_INFO et il sera placé dans le répertoire racine de la distribution source.

• PyPI

En 2002 , Richard Jones commence à travailler sur l'index des paquets Python, PyPI, plus connu sous le nom de Cheeseshop. La PEP 301 décrit Pypi. Distutils a été "tendu pour pouvoir envoyer une archive à un serveur centralisé. Apparaît alors la commande register (pour le setup.py) et le fichier .pypirc. De plus, dans le setup.py on a ajouté un concept de classification. La commande "register" a été ajoutée à Python 2.3. En 2003, le monde Python dispose maintenant d'un serveur centralisé PyPI où on peut pousser les archives décrites et classifiées selon les metadonnées.

• Setuptools

Philip Eby travaille sur setuptools en 2004 et 2005. Setuptools fournit un ensemble d'extensions à distutils tel que l'installation d'un format binaire (les egg), un outil automatique d'installation easy_install depuis le serveur centralisé. C'est une étape importante vers l'industrialisation des installations des applications Python.

• Virtualenv

Avec les eggs sont apparus des problèmes d'installation notamment au niveau des conflits de versions de ce qui était installé sur le système. Ian Bicking avec virtualenv fournit une solution à tout cela : virtualenv. Virtualenv fournit au développeurs un environnent Python spécifique à chaque projet sans pour autant polluer le système. On est en 2006.

• Buildout

En 2006, Jim Fulton crée buildout en s'appuyant sur easy_install et setuptools. Buildout crée lui aussi un environnement isolé du système mais plus ambitieux. L'objectif est de créer des installations reproductibles de projet complexe. L'industrialisation des installations est maintenant possible. L'intérêt de buildout est qu'il est facilement extensible en créant des recettes. Ces recettes étant aussi des eggs téléchargeables depuis PyPI. Cela donne tout un écosystème de recettes permettant de tout faire ou presque.

• Distribute

En 2008, setuptools est une pierre angulaire de l'infrastructure Python. Malheureusement setuptools a des défauts. Il est très centré sur son contributeur historique, Philip Eby. En raison de l'importance de la technologie à la communauté au sens large, les développeurs ont commencé à contribuer à diverses améliorations et corrections, mais celle ci s'accumulaient dans les trunk et les branches. Tarek Ziadé avec une dizaine de développeurs ont décidé de faire un fork de setuptools pour améliorer et corriger les bugs latents de setuptools. Distribute est maintenant intégré à virtualenv et buildout. Setuptools n'est plus un frein au packaging Python.

L'article original: http://faassen.n--tree.net/blog/view/weblog/2009/11/09/0