Vous êtes ici : Accueil Actualités Django 1.5 sur la rampe de lancement

Django 1.5 sur la rampe de lancement

L'actualité n'est pas des plus fraîches mais comme toujours, j'attends de tester le produit avant d'en parler. Le fait est que Django a commencé sa migration vers le support de Python 3 et que j'ai migré mes applications afin de tester le nouveau produit. Je vous propose mon retour d'expérience sur le sujet.

Parcours jusqu'à Django

Autant le dire tout de suite : je suis culturellement plus proche des architectures malléables que de celles monolithiques, en partie parce que je ne fait pas que du web mais surtout parce que j'aime gérer par moi même les choix architecturaux pour créer des applications techniquement homogènes alors qu'elles ne sont pas du tout faites pour les mêmes objectifs. Cela me permet de me concentrer sur quelques produits phares que j'ai pu préalablement et sans contraintes longuement tester et comparer et dont je ne cesse de rabattre les oreilles à tout le monde une fois que je les ai adopté - tels que SQLAlchemy, par exemple - et ainsi m'évite de réapprendre des technologies différentes pour faire au final la même chose.

Cela ne signifie nullement que les projets concurrents de ceux que j'ai choisi ne présentent pas d'intérêts à mes yeux, mais que je préfère passer du temps pour devenir un fin connaisseur d'un produit que je pourrais vraiment maîtriser, plutôt que de m'éparpiller et connaître beaucoup d'alternatives, mais à peu près.

Historiquement, venant du monde Zope 2 et 3, j'ai choisi d'évoluer vers un framework conçu pour fonctionner au dessus d'une base de données relationnelle, il y a maintenant quelques années (en 2005-2006). Turbogears m'a alors paru à ce moment là la meilleure solution et je l'ai énormément apprécié pour de multiples raisons tout en continuant de suivre d'un œil l'évolution de ses concurrents qui étaient CherryPy ou autre Pylons. Puis avec l'arrivée de Python 3 et de certains projets à contraintes particulières, il m'a fallu me tourner vers celui qui offre, selon mes critères et mes contraintes, les meilleures fonctionnalités ou en tout cas qui les fournissait à l'époque, puisque les choses bougent vite et que je n'ai pas refait de veille sérieuse sur ce sujet depuis plus d'un an, j'ai nommé Pyramid. Je dois avouer que j'ai été également très convaincu par un certain nombre d'aspects et que je n'hésite pas à m'inspirer très fortement de ce que Turbogears propose pour les fonctionnalités manquantes (et il en reste encore beaucoup, car toutes les dépendances dont j'aurais besoin ne sont pas portées).

Actuellement, je suis dans une phase bâtarde ou j'écris des composants dont je sais que je les abandonnerais dès que les composants que je souhaite réellement seront portés, ou une alternative crédible. En amorçant le choix de passer ce Turbogears vers Pyramid, j'ai décidé de me spécialiser dans la seconde technologie et de moins suivre la première, ce qui fait que je développe toutes mes nouvelles applications en Pyramid. Du moins, était-ce que je croyais.

Parce qu'un projet est vite arrivé et que certains d'entre eux ont des contraintes hallucinantes qui nécessitent l'utilisation de paquets python qui ne sont pas portés et qui ne le seront pas à moyen terme, parce que j'ai parfaitement conscience que Django est un formidable vecteur de diffusion du langage Python (il réussi plus que tout autre projet à faire venir des non Pythonistes et donc à faire connaître le langage Python), j'ai décidé il y a 8 mois de me lancer dans le développement Django et Python2.

Si le retour de Python 2 est parfois rude, les principes de Django se comprennent relativement bien même s'ils diffèrent de ceux que j'ai l'habitude de pratiquer. Pratiquer Django m'a fait voir de nouvelles façons de faire et même si pour mes autres développement je reste sur ma façon de faire, cette dernière s'est forcément enrichie de choses nouvelles que j'ai découvert avec Django, comme j'ai pu en découvrir avec d'autres technologies. Les différences avec les autres frameworks de ma connaissance sont loin ne sont que affaire d'habitude et j'ai validé à ce moment là l'idée que je m'en faisait auparavant : la qualité des trois solutions est parfaitement comparable. Les idées changent, la façon d'aborder les concepts change, mais pour l'essentiel, on s'y retrouve aisément.

Ainsi, j'ai réalisé un premier projet pour moi qui nécessitait des modules non portés, puis qu'en ai réalisé quelques-uns pour professionnellement. Parce qu'il s'agissait de projets courts en terme d'efforts de développement, mais avec suffisamment de marge pour les réaliser avec qualité en se donnant le temps d'apprendre, de tester, de pousser le produit, parce que je connaissais bien le PO (Product Owner), qu'il savait où l'on allait et qu'il me soutenait dans cette démarche, j'ai pu créer un petit parc applicatif Django à coté de mon parc Pyramid. (Toutes mes applications Turbogears avaient été converties en Pyramid).

Du coup, vous l'aurez compris, je ne suis pas un fan absolu de Django qui pense que c'est la seule solution valable dans le monde civilisé, mais plutôt un pythoniste avant tout qui aime l'efficacité et qui est prêt à fourrer son nez dans tout ce que la communauté peut proposer s'il y trouve de l'intérêt.

Verdict

Ces derniers temps, j'ai créé une nouvelle branche sur chaque projet Django, et je les ai porté sur la dernière version du framework.

La migration a nécessité certains changements, j'ai du aller assez loin pour comprendre la nature de certains bugs rencontrés, j'ai une version qui marchouille pas trop mal sur Python 2, mais le tout ne pourra pas du tout fonctionner sur Python 3, puisque Django n'est pas seul au monde. En effet, j'utilise des modules comme south ou werkzeug qui ne sont pas encore portés.

En réinstallant mes projets dans un environnement différent, en me séparant de ces modules et en résolvant un certain nombres de problèmes, j'ai pu arriver à une solution qui fonctionne pas trop mal, mais je n'en suis pas encore totalement satisfait. En effet, malgré le fait que je développe à la manière Python 3 dès que c'est possible, il faut forcément reprendre une partie du code lorsque la façon de faire entre Python 2 et Python 3 diffère et cela n'est pas imputable directement à Django, mais simplement au fait qu'une migration ne se fait pas en claquant des doigts et nécessite un certain travail, parfois long, parfois frustrant et qui peut être ressenti comme une perte de temps, ce qui objectivement n'est vraiment pas le cas.

La vision de Django est de proposer quelque chose qui fonctionnera sur Python 2 et Python 3. Étant donné les contraintes de leurs utilisateurs, la communauté doit tout faire pour ne pas les désorienter, pour ne pas les obliger à reprendre tout leur code pour une simple raison technique, ce qui aurait pour effet de donner une très mauvaise image au framework. Sur ce point là, c'est réussi grâce à l'utilisation de six et les détails sont .

Pour ma part, je n'ai donc rien rencontré d'autres que des points positifs et sachant que je place beaucoup d'espoirs dans le fait que Django mènera ses utilisateurs vers Python3, s'orientera vers des méthodologies de distribution plus pythoniques et continuera à se diffuser, tirant Python derrière lui, je me mets également à espérer qu'il entraînera avec lui des projets comme south ou werkzeug dans cette démarche de migration.

Rappelons également que Python 3.3 devrait apporter des facilités pour la migration, ce qui est une autre raison pour espérer que celle-ci s'accélère (voir les autres actus sur le sujet sur ce site).

Pour terminer, avec la migration de Django, 17 des 20 projets Python les plus populaires (téléchargés) sont maintenant portés (Django est 12ième dans la liste). Ils sont 38 sur les 50 premiers et parmi les non portés, on trouve effectivement south et werkzeug. On trouve également MysqlDb dont on a déjà parlé ainsi que d'autres projets liés au Web que sont Paste, Pastescript et Flask.

Terminons en rappelant que la version 1.5 définitive devrait sortir avant la fin de l'année.

Spinner