Publication de Pyramid 1.5

Posté par  . Édité par fero14041, wilk, BAud, Benoît Sibaud, palm123, Nÿco, gawel, Cyprien Le Pannérer, Bruno Michel, claudex, tuiu pol, NeoX, Nicolas Casanova et Ymage. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
36
5
mai
2014
Python

Sept mois après la sortie de la version alpha, la version 1.5 est disponible en version stable. Pyramid est un framework Python (Python2 et Python3) pour le développement de sites web, développé avec le projet Pylons (qui regroupe justement des frameworks web), sous licence libre BSD.

Pyramid

Sommaire

Petite introduction

La particularité de ce framework est d'être « sans opinion » : il ne fournit pas d'ORM ni de template par défaut et il n'est pas indispensable d'utiliser toutes les possibilités offertes. On ne « paye » que ce que l'on consomme. Cela lui permet de répondre aux petites applications se contentant d'un seul fichier. Il est également extrêmement flexible ce qui lui permet de développer les projets les plus complexes sans avoir à changer de framework en cours de route.

Par exemple, on peut commencer un projet sans contrôle d'accès puis lui rajouter un système d'authentification simple et, ensuite, un système plus complet à base d'ACL ou d'autres systèmes extérieurs agencés pour Pyramid.

Pratiquement toutes les fonctionnalités de Pyramid sont extensibles, que ce soit le système de routes (classique URL Dispatch ou sur un arbre de ressources Traversal), les sessions (sur cookie signé ou à l'aide d'un système externe, beaker, redis…), les templates (éventuellement plusieurs en fonction des vues), les vues (sous forme de fonction ou classes), les contrôles d'accès, etc.

Un mécanisme de souscription permet d'insérer ses propres fonctionnalités à tous les niveaux. Du lancement de l'application au parcours de la requête (création de la requête, rendu, création de la réponse, etc.). Il est même possible d'ajouter ses propres évènements, d'y souscrire et de les lancer.

Il est également possible de développer une application par morceaux à inclure, chacun défini avec un préfixe éventuel donné par la configuration principale config.include('package', route_prefix='/...') . Préfixe qui sera automatiquement utilisé par request.route_url('route_name')
Par exemple, il sera possible de développer la partie admin d'un site à part puis de l'intégrer dans /admin par la suite.
Cette partie incluse pourra également être redéfinie sur trois aspects. La redéfinition des vues pour en modifier le code, la redéfinition des routes pour diriger vers une autre vue et la redéfinition des 'assets' pour remplacer des données statiques et des templates.

Tant et si bien que l'on peut utiliser Pyramid comme un jeu de mécano, pour construire son propre framework ou inversement passer d'un autre framework vers Pyramid. Sachant qu'il n'est absolument pas indispensable de connaître toutes ses possibilités pour se servir de Pyramid.

La documentation couvre l'ensemble des fonctionnalités de manière exhaustive. En plus de cela, la raison de chaque choix technique est expliquée, ce qui en fait une documentation intéressante, à lire même pour ceux qui n'utilisent pas Pyramid. Dans le chapitre "Defending Pyramid's Design" une comparaison est faite avec les choix techniques des autres frameworks.

Les nouveautés

Aucun moteur de template par defaut

Aucun moteur de template n'est maintenant installé par défaut. Les dépendances précédentes à Chameleon et Mako ne sont donc plus requises pour installer Pyramid. L'écosystème d'outils gagne alors deux nouveaux projets pour faire le lien avec chacun de ces moteurs: pyramid_chameleon et pyramid_mako, complétant le trio par pyramid_jinja2 pour Jinja2—qui leur préexiste depuis 2010.

pdistreport est un script installé avec Pyramid qui fournit des informations sur la version de Python utilisée et les versions et emplacements des modules installés par pip ou easy_install.

Un nouveau predicat : not_

Un nouveau prédicat permet, comme son nom l'indique, d'inverser la directive qu'il contient. Il peut être utilisé pour l'ajout d'une vue : add_view, add_route, add_subscriber, view_config et subscriber7

from pyramid.config import not_

@view_config(route_name='myroute', request_method=not_('POST'))
def view(request):
    ...

Ainsi, dans l'exemple ci-dessus, la vue view sera appelée sur toute requête HTTP autre que POST.

Sessions

SignedCookieSessionFactory remplace UnencryptedCookieSessionFactoryConfig (attention il y a incompatibilité sur les sessions en cours).

Dépréciation de Beaker

Beaker, le système de gestion de sessions et de cache, développé pour le framework Pylons, n'est plus recommandé pour gérer les sessions : on lui préférera Redis, via pyramid_redis_sessions. Pour gérer le cache, on pourra lui substituer dogpile.cache, développé par Mike Bayer (père de SQLAlchemy et Mako).

pyramid_pluggable_session

Pour remédier à l'obsolescence de Beaker, qui fait couler beaucoup d'encre sur la liste de discussion de Pyramid, un nouveau projet vient de naître : pyramid_pluggable_session, il permet d'ajouter facilement un système de persistance à l'aide d'un object IPlugSession comprenant deux méthodes loads(session, request) et dumps(session, request, session_data) . Un exemple de persistance en mémoire et sur fichier est déjà présent.

Route externes

Les routes peuvent maintenant référencer des routes externes. Ces routes sont implicitement statiques.
Il est possible de ne pas spécifier le protocole (scheme) http ou https. Comme en Javascript, le protocole sera le même que celui de la requête.

>>> config = Configurator()
>>> config.add_route('youtube', '//youtube.com/watch/{video_id}')
>>> request.route_url('youtube', video_id='oHg5SJYRHA0')
"https://youtube.com/watch/oHg5SJYRHA0"

Prise en charge de l'héritage dans la recherche des vues

request.exception et request.exc_info ne sont plus effacés avant les finished_callback

Ce bug a été corrigé, il permet maintenant de savoir lors d'un finished_callback si une exception a eu lieu ou pas.

Exemple sur une transaction :

def _connect(request):
    conn = request.registry.dbsession()
    def cleanup(request):
        if request.exception is not None:
            conn.rollback()
        else:
            conn.commit()
        conn.close()
    request.add_finished_callback(cleanup)
    return conn

@subscriber(NewRequest)
def new_request(event):
    request = event.request
    request.set_property(_connect, 'db', reify=True)

Documentation

La documentation du framework a toujours été à la fois un de ses atouts et un de ses défauts : extrêmement détaillée, elle a ravi les utilisateurs convaincus de l'outil, tout en faisant probablement fuir de nombreux débutants. L'équipe de développeurs en était bien consciente et avait lancé il y a plusieurs mois un appel aux dons pour la restructurer et la rendre plus accessible, mais le projet n'avait finalement pas démarré.

L'idée a cependant été reprise récemment par Paul Everitt, qui a joint à la documentation existante deux nouveaux points d'entrée : un « Quick Tour » (visite rapide) du framework, et un « Quick Tutorial » (bref tutoriel).

Nouveau thème pour les projets créés par scaffold

Une autre des caractéristiques de Pyramid est d'offrir un ensemble de "template" de projets pour en démarrer un, utilisé par la commande pcreate (doc). Pour distinguer ces templates de ceux utilisés pour générer les réponses HTTP, la documentation les nomme "scaffolds". Pour cette version, les scaffolds fournissent, à la création d'un nouveau projet, un thème graphique entièrement retravaillé.

Thème du scaffold "starter" de Pyramid 1.4

Nouveau thème du scaffold "starter" de Pyramid 1.5

En vrac

  • À l'occasion de cette sortie, l'artiste Felix Laflamme, graphiste attitré du projet, a créé un nouveau T-shirt qui fut très visible au Pycon. Vous pouvez retrouver les précédentes créations sur la page de la boutique.
  • La bibliothèque WSGI bas niveau de gestion des requêtes et réponses HTTP sur laquelle s'appuie le framework, WebOb, est maintenant requise à partir de sa version 1.3.1 (contre 1.2b3 pour Pyramid 1.4).

Les changements sont trop nombreux pour tous les citer ici. Vous pouvez consulter les liens pour plus d'informations

Aller plus loin

  • # Pyramid vs ..

    Posté par  . Évalué à 5.

    A chaque fois que l'on présente un soft il y à toujours la question "mais qu'est ce que X fait par rapport à Y"? :
    - si tu présente vim le noob te demandera "oui mais qu'est ce qui est mieux : vim vs emacs?"
    - si tu présente BeagleBone, "oui mais BeagleBone vs RaspberryPI ?"
    - etc..

    je ne dérogerai donc pas à cette règle, puisque, assumant ma position de noob web (ça fait contrepèterie) , je souhaiterai demander :> "oui mais Pyramid vs Flask ?". Certes, il me semble y avoir plus de fonctionnalités dans Pyramid (j'ai fait le Quicktour) mais si je veux faire un site chez free, est ce que cela ne risque pas d'être trop lourd néanmoins ?

    • [^] # Re: Pyramid vs ..

      Posté par  . Évalué à 5.

      Je ne connais pas assez flask pour une réponse sérieuse Flask vs Pyramid. Par contre je doute que pyramid soit énormément plus lourd que Flask.

      Pour ma part les avantages de Pyramid sont la fiabilité (ce qui n'est pas testé est cassé), la documentation et une solide réponse sur les choix techniques. Ce dernier point est particuliérement intéressant car cela permet d'identifier les atouts/contraintes d'un framework.

      Comme précisé dans la dépêche Pyramid est fortement agnostique avec les avantages (flexibilité) et les inconvénient (retrousse tes manches, fais tes choix). Les fonctionnalités viennent plutot s'ajouter comme une agrégation ce qui favorise l'utilisation d'outils externe (et réduit les fonctions disponibles de base).
      La fonction de debug est vraiment pratique aussi et vient également s'agréger à ton application pour afficher un profiler, les résultats des routes en plus d'un tracebakc identique à celui de Flask…
      La sécurité est également un point particulier si on utilise traversal, venu du monde plone, qui permet une sécurité par objet. Très pratique pour des application de gestion de contenu avec la possibilité de définir des ACL du genre : le propriétaire de cet objet, un membre du même groupe, une participant à une activité…

      Il n'y a pas de debug mode au sens Flask mais des fonctions activées ou pas en général dans un fichier de configuration (ini) passé en paramétres.
      Bref quelques différences mais rien de bloquant dans un sens ou dans l'autre.

    • [^] # Re: Pyramid vs ..

      Posté par  . Évalué à 6.

      Une vidéo de l'auteur de Pyramid sur la différence avec django qui pourra aiguiller
      http://pyvideo.org/video/1407/about-django-from-the-pyramid-guy

      Il n'a pas plus de fonctionnalités que Flask, il en a même moins (pas de template, pas de session côté serveur…), sa particularité est d'être pensé dès le départ pour être flexible et extensible, le lien "Defending Pyramid's Design" explique bien comment et pourquoi ces notions sont mises en place.
      Quelques détails : le système de route est plus explicite et robuste, on peut inclure une application dans une autre sans risquer de conflit. Pyramid n'utilise pas threadlocal, le passage de request est toujours explicite, cela facilite les tests et l'inclusion d'applications. Les Tweens remplacent les middlewares, ils bénéficient ainsi du "contexte". Il y a quantité de petits hooks et paramètres pour obtenir un comportement personnalisé. Compatible py3. Bref on voit dans les petits détails que tout a été pensé pour que l'application puisse évoluer sans limite et de manière robuste sans être pour autant pénalisée au début. L'utilisation basique reste quasi identique à Flask. On pourrait très facilement imaginer construire Flask ou Django sur Pyramid. Il faudrait d'ailleurs plutôt les comparer à
      https://github.com/ptahproject/ptah

      Etant donné la quantité de petits détails techniques qui font la différence, il faut se plonger dedans pour en mesurer les avantages. J'ai été convaincu quand j'ai essayé de migrer de mon framework perso, qui commence à sentir le renfermé, vers un framework plus ouvert. J'ai pu l'adapter progressivement (et surtout de manière très propre) vers Pyramid sans avoir à changer une ligne de mes applications (dont certaines ont plus de dix ans) ! Ce qui m'assure l'inverse, à savoir que demain un Pyramid 2 ne m'obligera pas à changer mes applications, problème majeur des frameworks.

      Pour répondre à ta question de noob, c'est l'éternelle question que l'on retrouve dans la "philosophie unix", est-ce que tu veux continuer à rester noob ou pas ;-) ?

      • [^] # Re: Pyramid vs ..

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Je rajouterais que Flask/Bottle et Pyramid peuvent être utilisés de concert, puisque ce sont tout deux des applications WSGI.

      • [^] # Re: Pyramid vs ..

        Posté par  . Évalué à 1.

        Merci beaucoup pour cette réponse, et les pointeurs inclus. Effectivement, sous ma question innocente ascendant trollifère j'ai du coup appris ce qu'il me fallait. Car effectivement la philosophie Unix/DIY me va bien.

    • [^] # Re: Pyramid vs ..

      Posté par  . Évalué à 3.

      Une petite présentation qui montre quelques exemples concrets sur les possibilités d'extensions :
      http://compiletoi.net/slides/europython2013-pyramid/

    • [^] # Re: Pyramid vs ..

      Posté par  (site web personnel) . Évalué à 6.

      J'ai fait pas mal de Pyramid depuis on va dire 3 ans ou plus (je me souviens plus, avant je faisais du Pylons 1 et repoze.bfg) et un peu de Flask depuis quelques mois.

      Mes commentaires :

      Conclusion, j'aime bien les deux. J'ai plus d'habitude avec Pyramid mais j'ai l'impression que Flask me donne un tout petit peu plus de souplesse.

      • [^] # Re: Pyramid vs ..

        Posté par  . Évalué à 2.

        Pourquoi tu te sens obligé d'utiliser paste pour lancer tes applis Pyramid ? Je préfère aussi, pour l'instant, les lancer et les configurer directement en python.
        D'après ce que je vois sur ton lien la syntaxe à l'air même assez proche sur la partie basique (config.settings) et surtout plus complète avec les includes qui permettent d'inclure tout un pan de programme, configuration, extension sans crainte de conflit.
        Un exemple, http://cms.nive.co où la configuration de l'appli est particulièrement copieuse et donc en python.

        Les snippets sont là : http://docs.pylonsproject.org/projects/pyramid-cookbook/en/latest/ mais c'est vrai que vu les possibilités de Pyramid il est encore un peu difficile de trouver les exemples qu'on cherche.

        Quelle genre de souplesse tu trouves d'avantage à Flask ?

  • # Migration de Turbogears vers Pyramid ?

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Est-ce que des personnes ont fait une migration de Turbogears vers Pyramid ? Si oui, ça se passe comment ? Il était question à un moment que Turbogears migre vers Pyramid, mais ça ne semble plus trop d'actualité ; l'intérêt que je vois dans Turbogears c'est d'offrir une solution full-stack basée sur des composants "classiques" (webob, sqlalchemy, etc), mais ça semble moins flexible (et moins dynamique) que Pyramid.

    #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

  • # Pyramid — Django

    Posté par  (site web personnel) . Évalué à 1.

    Est-ce vraiment si bien que ça de devoir choisir un ORM, un moteur de template, un système d'authentification, … ?

    Je dois avoir une vision déformée par l'abus de Django, mais j'ai du mal à croire que ça soit si pratique que ça au quotidien.
    Après, ok, on peut faire un site en un seul fichier, mais à nouveau, je ne suis pas convaincu de l'utilité. De toute façon, il faudra bien ajouter un ORM, des templates, une couche d'authentification, …

    Quand je démarre un site Django, j'ai un générateur pour me faire la structure du code (avec la conf pour la base de données, le système d'authentification, …), et j'ai un truc immédiatement fonctionnel avec un découpage logique et surtout toujours standard, ce qui rend les choses bien plus faciles pour se plonger dans un code externe.

    • [^] # Re: Pyramid — Django

      Posté par  . Évalué à 2. Dernière modification le 07 mai 2014 à 22:38.

      Ce sont deux approches différentes, avec chacune ses avantages et inconvénients. Pour moi, l'avantage du tout-en-un est à court terme, on se pose moins de questions, on peut démarrer un projet plus rapidement. Mais qu'en sera-t-il lorsque le projet évoluera ? Comment faire évoluer une partie du framework ?
      L'avantage du mode "briques", typique de la philosophie unix, c'est que l'on peut évoluer progressivement, chaque partie à son rythme et quand on le souhaite. Le temps que l'on perd au démarrage on le rattrape par la suite. On peut aussi créer des scaffolds pour faciliter la création de nouveaux projets.
      C'est vrai que ça rend plus compliqué le partage avec la majorité, c'est l'inconvénient de la diversité.

      La démonstration du site en un seul fichier ça n'est pas tant pour être utilisé tel quel, c'est simplement pour montrer que les possibilités étendues n'ont pas été faites au détriment de la simplicité. Ce qui est simple reste simple, ce qui est complexe reste possible sans en rajouter.
      Le peu que j'ai utilisé Django j'ai trouvé que tant qu'on reste dans la norme tout va bien, mais dès qu'on veut faire plus simple c'est pas simple, et si on veut faire plus compliqué ça devient trop compliqué. Mais c'est très personnel car j'ai beaucoup de vieux codes à réutiliser et à maintenir très longtemps.

    • [^] # Re: Pyramid — Django

      Posté par  . Évalué à 6.

      La dernière fois que j'ai regardé django ne gérer pas les bases noSQL (ou pas toutes ou pas pour sauvegarder son modèle). C'est limitant tout de même.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Pyramid — Django

        Posté par  (site web personnel) . Évalué à 1.

        Tu peux maintenant faire du noSQL, au moins avec LDAP, Neo4j et MongoDB.

        • [^] # Re: Pyramid — Django

          Posté par  . Évalué à 4.

          Donc pas de couchdb, pas de base orienté colonne, pas de base clef-valeur,etc

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Pyramid — Django

      Posté par  . Évalué à 2.

      Je dois avoir une vision déformée par l'abus de Django, mais j'ai du mal à croire que ça soit si pratique que ça au quotidien.
      Après, ok, on peut faire un site en un seul fichier, mais à nouveau, je ne suis pas convaincu de l'utilité. De toute façon, il faudra bien ajouter un ORM, des templates, une couche d'authentification, …

      Django est le contre-exemple par excellence. L'ORM de Django est extrêmement limité par rapport à SQLAlchemy, malheureusement Django est fait pour s'interfacer uniquement avec son propre ORM et pas avec SQLAlchemy…

      • [^] # Re: Pyramid — Django

        Posté par  (site web personnel) . Évalué à 1.

        L'ORM de Django s'est quand même beaucoup amélioré avec les dernières versions. Cela dit, je ne connais pas spécialement SQLAlchemy. Mais pour ma culture personnelle, qu'est-ce qui est possible sur SQLAlchemy et qui ne l'est pas avec Django ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.