G.bleu a écrit 186 commentaires

Je me suis arrêté à"Nazie", j'ai bien fait ?

Au minimum, j'attendrais une vraie version 3.0 considérée stable avant de me lancer là-dedans.

Tout à fait d'accord.

Comme tu dis l'équipe est petite et si le moteur une dizaine d'années, il n'a été libéré que fin 2014 ce qui fait qu'il est encore dans une phase d'expansion avec des release apportant beaucoup (la v3 est incroyablement fourni avec entre autres un nouveau moteur audio et de rendu !).
En tout cas les bases sont de qualité, la communauté est réellement présente et le projet avance de manière très encourageante (ayant testé le moteur à sa libération, le chemin parcouru est énorme).

À ce rythme, je vois bien ce projet devenir une vrai alternative libre à Unity à l'image de ce que fait Gimp ou Blender dans leurs domaines respectifs.

Par contre, il est question de wrapper avec C#.

Python est aussi en chantier ;-)

PS: allez voir le devblog du projet qui est super intéressant et mis à jour régulièrement !

C'est sûr que ça fait un sacré argument pour passer à lua: tu balances ses 800ko de .c/h en vrac dans tes sources et basta, plus personne ne viendra t'emmerder après ça ;-)

J'étais parti pour ignorer ton premier post, ou plutôt apprécier le fond en passant outre de la forme ;-)

Si je viens sur LinuxFR c'est pour apprendre des choses et échanger, une dépêche sur BSD c'est le moment idéal pour en apprendre plus.

Si une personne que ne connais pas Linux vient demander pourquoi l'utiliser alors que Windows est ultra majoritaire (en tout cas de son point de vu, dans sa vie il ne côtoie pas de serveurs et ne se doute pas que Linux tourne dans sa poche), on va le traiter de gros troll ?

J'ai mis DEUX putains de disclaimer, au début et à la fin de mon post, j'ai cherché à être le plus neutre possible (je reconnais, je n'aurai pas dû mettre "aucun support d'entreprises commerciales" mais "pas de support commercial à ma connaissance"), j'aurai dû faire quoi de plus ? Fermer ma gueule et rester un ignare ?

Autant prévenir d'avance : je ne cherche pas le troll et ma question est purement de bonne fois !

Je n'ai pas beaucoup d'expérience avec les bsd (freeBSD installé sur mon portable et utilisé pendant 1mois quand j'étais étudiant "pour voir") et je ne vois pas beaucoup d'intérêt aux BSD par rapport à linux: le support matériel et la correction des bugs/ajout de features ne peut pas suivre le rythme (communauté beaucoup plus petite, aucun support d'entreprises commerciales).
Au final les seuls avantages des BSD à ma connaissance sont que pf est vachement mieux que iptable et que openbsd est fourni durci de base.

Du coup ça ne fait pas très lourd, et ça pose donc des questions:
- pourquoi pf n'a pas été porté sous linux ? (Ou au moins son interface user)
- une openBSD est elle vraiment plus sécurisé qu'un linux ? Si oui pourquoi Google&co continue à faire tourner linux pour leurs serveurs ?
- pourquoi on a 4 versions de BSD ? De ce que je sais y'a eu pas mal de forks plus ou moins cordiaux…
- qui utilisent ces 4 BSD, pourquoi (ils ont un cas d'utilisation différents chacun ?) et surtout pourquoi ne pas utiliser linux à la place ?
- est-ce que ces os sont plutôt dans une logique de recherche plutôt que de production comme haiku ou plan9 ?

Je le répète, je ne cherche pas à dire que BSD est un os de hypsters ("I was doing sockets before it was cool") sans intérêt mais plutôt à comprendre comment et pourquoi 4 OS arrivent à sortir des versions à rythme régulier alors que le marché des OS libres est totalement contrôlé par linux.

À mon avis il parlait surtout de PHP qui a été remplacé par ruby, lui même remplacé par nodejs dans le rôle du "langage hype".

Côté front on parle beaucoup de réaction en ce moment et vu comment la communauté est girouette, les anciennes starlettes comme angular ont tendance (à tord à mon avis) à être considéré comme has been…

Pour avancer sur ta réflexion, je retirerai la mention 5ans de PHP. Tu as besoin d'un "mec pas con" (tm), tant qu'il a fait 5ans (je dirais même 3ans) de dev web ça peut faire le taff.
Dans ma boîte on a recruté des mecs venant du logiciel financier en c/c++ pour faire du python web, adaptation sans aucuns soucis. C'est justement ton rôle de voir si ça va le faire lors des entretiens donc autant ouvrir la porte à un maximum de candidats.

Je développement un programme pour automatiser une procédure, je choisi une syntaxe lisible et simple à comprendre

Tu devrais surtout bosser ta syntaxe sur tes posts…

Lors du dernier Python language summit (réunion privée des core développeurs qui se tient en marge de la PyCon US), l'équipe derrière Pyjion est intervenue pour présenter l'avancée de leur travail (voir https://lwn.net/Articles/691152/)

Concrètement l'objectif du projet Pyjion est d'ajouter une API à l'interpréteur CPython afin de pouvoir y brancher un JIT.
L'idée étant de laisser libre l'implémentation du JIT en question, pour la preuve de concept ils utilisent coreclr (le JIT de .net) mais pensent à passer sur Chakracore (notamment pour supporter l'achitecture ARM).

Je répond à barmic, Elfir3 et wilk d'un coup : mon post cherchait à mettre en avant des projets qui ont eu une croissance monstrueuse et sans que leur technologie sous-jacente ne leur mette (trop) de batons dans les roues.

Une fois ces projets devenus les monstres qu'on connait, ils ont cherché à améliorer leur existant, l'optimiser faire des expérimentations. Bref occuper les ouatmilles ingénieurs surqualifiés qu'ils avaient embauché (genre twitter qui fait son framework Java à la place de J2E, Facebook qui fait Hack etc.). C'est dans ce context qu'ils ont réalisé les évolutions de leur stack de base.

Car soyons franc : si la définition de scalé est « être capable de gérer un service de la taille de Facebook out-of-the-box », alors aucune technologie ne scale !

Pour la scalabilité, Python (et probablement ruby et PHP) sont à la ramasse au bout d'un moment.

Python propulse Youtube, Dropbox, Hipchat et Reddit
PHP : Facebook et Wikipedia
Ruby : Heroku et Twitter
node.js : Paypal (qui remplace Java d'ailleurs)

T'es plus en 2005, les gens ont arrêté de croire que parce que y'a que java qui a une « édition entreprise » les autres technos sont des trucs pour gamins qui scale pas.

Sommaire

• • Pyparsing
  • Parcimonious
  • Bilan

Super journal, mais pourquoi n'a-t'il pas déjà été promu en dépêche ;-)

Tombant d'autant plus à pic que Grako vient de sortir une version 3.9.3 le 30 juin dernier.

Personnellement j'avais essayé parcimonious et pyparsing.
Contrairement à Grako qui génère du code python à utiliser dans son application, parsimonious et pyparsing
sont à utiliser comme une lib standard dans laquelle on définie une grammaire chargée à l'exécution.
C'est en fait ce que tu fais via l'intégration de l'outil en ligne de commande Grako à ton code, je pense
même que ça mériterai que tu soumettes une PR pour ajouter cette fonctionnalité à la lib de base.

Pyparsing

Pyparsing (passé en 2.1.5 le 13 juin dernier, décidement c'est le mois !) fourni un moyen pythonique de définir sa grammaire :

from pyparsing import Forward, Combine, Word, Optional, Literal, ZeroOrMore, nums

expression = Forward()

nombre = Combine(Word("+-"+nums, nums) + Optional(Literal('.') + nums)).setName('nombre')
facteur = (Literal("(").suppress() + expression + Literal(")").suppress()).setName('facteur') | nombre

terme = ZeroOrMore(facteur.setResultsName('left') + Word('* /').setResultsName('op')) + facteur.setResultsName('right')
expression << ZeroOrMore(terme.setResultsName('left') + Word('+ -').setResultsName('op')) + terme.setResultsName('right')

ast = expression.parseString("45 + 98 / (76 * 2)")
print(ast.asDict())

Qui retourne

{
    'left': '76',
    'op': '* ',
    'right': {
        'left': '76',
        'op': '* ',
        'right': '76'
    }
}

On remarque les suppress pour exclure un token de l'ast ainsi que setResultsName qui est l'équivalent de la syntaxe de nommage de Grako.
On peut voir aussi l'utilisation de l'objet Forward permettant de faire référence à un élément avant sa définition.

Une option intéressante est de pouvoir utiliser la méthode setParseAction permettant de déclencher une fonction prenant le nœud du token
en argument. Cela permet de customiser l'ast, voir de faire son évaluation pendant cette phase.

Toutefois d'un point de vu ressenti personnel, je trouve qu'on galère beaucoup pour écrire sa grammaire justement à cause de ce problème de forward.
Dans mon exemple j'utilise des ZeroOrMore pour éviter d'utiliser de la récursion (les forwards donc) qui en général ne
fait rien d'autre que des erreurs de parsing plus ou moins abscons.
De plus on perd la compatibilité avec la syntaxe BNF ce qui rend les choses plus compliqués si on veut réimplémenter dans un autre langage.

Parcimonious

Parcimonious avait une syntaxe plus proche d'une bnf :

RAW_GRAMMAR = """
expression = addition / soustraction / terme
addition = terme ws "+" ws expression
soustraction = terme ws "-" ws expression
terme = multiplication / division / facteur
multiplication = facteur ws "*" ws terme
division = facteur ws "/" ws terme
facteur = ("(" ws expression ws ")") / nombre
nombre = ~"[-+]"? chiffre+ ("." chiffre+)?
chiffre = ~"[0-9]"
ws = ~"\\s*"

parser = Grammar(RAW_GRAMMAR)
ast = parser.parse("45 + 98 / (76 * 2)")
print(ast)

Le résultat est très verbeux :

<Node called "expression" matching "45 + 98 / (76 * 2)">
    <Node called "addition" matching "45 + 98 / (76 * 2)">
        <Node called "terme" matching "45">
            <Node called "facteur" matching "45">
                <Node called "nombre" matching "45">
                    <Node matching "">
                    <Node matching "45">
                        <RegexNode called "chiffre" matching "4">
                        <RegexNode called "chiffre" matching "5">
                    <Node matching "">
        <RegexNode called "ws" matching " ">
        <Node matching "+">
        <RegexNode called "ws" matching " ">
        <Node called "expression" matching "98 / (76 * 2)">
            <Node called "terme" matching "98 / (76 * 2)">
                <Node called "division" matching "98 / (76 * 2)">
                    <Node called "facteur" matching "98">
                        <Node called "nombre" matching "98">
                            <Node matching "">
                            <Node matching "98">
                                <RegexNode called "chiffre" matching "9">
                                <RegexNode called "chiffre" matching "8">
                            <Node matching "">
                    <RegexNode called "ws" matching " ">
                    <Node matching "/">
                    <RegexNode called "ws" matching " ">
                    <Node called "terme" matching "(76 * 2)">
                        <Node called "facteur" matching "(76 * 2)">
                            <Node matching "(76 * 2)">
                                <Node matching "(">
                                <RegexNode called "ws" matching "">
                                <Node called "expression" matching "76 * 2">
                                    <Node called "terme" matching "76 * 2">
                                        <Node called "multiplication" matching "76 * 2">
                                            <Node called "facteur" matching "76">
                                                <Node called "nombre" matching "76">
                                                    <Node matching "">
                                                    <Node matching "76">
                                                        <RegexNode called "chiffre" matching "7">
                                                        <RegexNode called "chiffre" matching "6">
                                                    <Node matching "">
                                            <RegexNode called "ws" matching " ">
                                            <Node matching "*">
                                            <RegexNode called "ws" matching " ">
                                            <Node called "terme" matching "2">
                                                <Node called "facteur" matching "2">
                                                    <Node called "nombre" matching "2">
                                                        <Node matching "">
                                                        <Node matching "2">
                                                            <RegexNode called "chiffre" matching "2">
                                                        <Node matching "">
                                <RegexNode called "ws" matching "">
                                <Node matching ")">

Contrairement à pyparsing, pas d'équivalent à suppress ici, mêmes les espaces sont présent dans l'ast
(ici sous la forme de la règle ws).

Il faut donc gérer ça dans le visitor parcourant l'ast :

class Visitor(NodeVisitor):

    def visit_expression(self, n, vc):
        return vc[0]

    def visit_addition(self, n, vc):
        left, _, _, _, right = vc
        return left + right

    def visit_soustraction(self, n, vc):
        left, _, _, _, right = vc
        return left - right

    def visit_term(self, n, vc):
        return vc[0]

    def visit_multiplication(self, n, vc):
        left, _, _, _, right = vc
        return left * right

    def visit_division(self, n, vc):
        left, _, _, _, right = vc
        return left / right

    def visit_facteur(self, n, vc):
        if len(vc) == 1:
            return vc[0]
        else:
            return vc[2]

    def visit_nombre(self, n, vc):
        return float(n.text)

    def generic_visit(self, n, vc):
        return vc[0] if vc else n


Visitor().visit(ast)

Niveau débuggage, c'est là encore pas très confortable, exemple:

>>> print(vc)
[s = '(76 * 2)'
Node('', s, 0, 1), s = '(76 * 2)'
RegexNode('ws', s, 1, 1), 152.0, s = '(76 * 2)'
RegexNode('ws', s, 7, 7), s = '(76 * 2)'
Node('', s, 7, 8)]

Là il faut comprendre qu'on a une liste de nœuds, simplement leurs __repr__ retournent une string contenant un retour à la ligne et pas de séparation claire !
J'aurai préféré un truc du style :

[<s = '(76 * 2)', Node('', s, 0, 1)>,
<s = '(76 * 2)', RegexNode('ws', s, 1, 1)>,
152.0,
<s = '(76 * 2)', RegexNode('ws', s, 7, 7)>,
<s = '(76 * 2)', Node('', s, 7, 8)>]

Je devrais leur faire une PR mais vu que le projet n'a pas évolué depuis 2 ans…

Bilan

Je n'ai été qu'à moitié convaincu par ces deux lib, je pense que pyparsing est pas mal pour les petites grammaire
en raison de son API et de sa capacité à évaluer les nœuds tout en les parsants.
Parsimonious de son côté me semble trop simple et son développement semble stoppé (pas de maj depuis 2ans), à éviter donc.

J'avais d'abord intégré l'utilisation de générateurs de sites statiques (Pelican, Hugo, Lektor et Jekyll), mais j'ai laissé tombé devant la complexité de la sécurisation du processus (plugins, évolution des générateurs à surveiller, etc).

Si je comprends bien, FsPages se contente de publier verbatim le contenu d'une branche sans phases de traitement comme ferait github pages ?

D'ailleurs en parlant de Github pages, ceux-ci utilisent Jekyll et sont donc confrontés à la complexité de sécurisation dont tu parles. Sais-tu comment ils font ? (ils mettent plus de monde sur le projet, utilisent des machines virtuelles séparées pour chaque génération etc.)

C'est deux philosophies complémentaires :
- d'un côté Django est sans prise de tête, tout est déjà pensé et intégré pour un workflow standard
- de l'autre Flask est pensé pour être le plus simple possible et répondre aux besoin par des extensions

Au niveau fonctionnalités je dirais que les deux sont grossos-modo équivalents, par exemple :
Django ORM ==> SQLAlchemy
Django admin ==> Flask admin
Django rest framework ==> Flask restful

La principale différence serait que Flask permet de choisir son ORM là où Django repose sur son module interne (il y a eu des initiatives pour permettre d'utiliser mongoDB, mais je ne sais pas où ça en est).

Personnellement j'adore la simplicité de Flask, cela permet d'intégrer des personnes n'ayant pas d'expérience avec la techno très simplement et ça encourage à lire le code source.

Au final il n'y a pas de mauvais choix entre les deux [vendredi c'est permis]et si ton équipe est parti sur l'un des deux ça veut dire que t'as éviter PHP et nodejs donc te plains pas ![/vendredi c'est permis]

J’ai l’impression que Python 3 n’est pas encore correctement supporté.

J'ai plusieurs applications en production sur Flask + Python 3, jamais eu le moindre bug à cause de Flask.

Le plus gros soucis de cette version pour moi est l'arrivée de click en dépendance.

L'issue (https://github.com/smurfix/flask-script/issues/97) résume bien le bordel :

mitsuhiko (Armin Ronacher, le créateur de flask), écrit le 7 mai 2014 :

Mon plan est que d'ici le mois prochain il y ait une nouvelle release de Flask avec Click embarqué ainsi que la recommandation de l'utiliser
[…]
Vu combien d'extensions utilisent Flask-Script actuellement et à quel point il est devenu populaire, j'aimerai qu'on puisse trouver une solution pour tout migrer sur Click sans pour autant causer à tous beaucoup de frustration.
[…]
Pour répondre à la question évidente pourquoi pas Flask-Script:
Flask-Script est vieux et victime de deux changements majeurs dans Flask. Le principal problème est que Flask-Script lance un contexte de requête même si il n'y a pas de raisons de faire cela.
Flask-Script charse l'application très tôt ce qui cause des soucis pour le rechargeur (reloader) pendant le développement.En particulier cela veut dire qu'une erreur de syntaxe va faire crasher le rechargeur. Ce veut aussi dire qu'avec le rechargeur activé, le code de plus haut niveau est exécuté deux fois. L'intégration de click dans Flask résout cela.
[…]

Réponse de miguelgrinberg (grosse pointure dans la communauté, a notamment écrit le flask mega tutorial) le 9 mai 2014

@mitsuhiko J'ai jeté un coup d’œil à ta couche d'intégration de Click. Il semblerait que le code qui s'occupe de résoudre les deux limitations de Flask-Script que tu as mentionner ne sont pas spécifiques à Click du tout.
En fait, en quelques minutes de hacking, j'ai été capable de résoudre les soucis avec Flask-Script de la même manière.
[…]

S'ensuit quelques discutions sur le comment et malheureusement pas assez le pourquoi.

Et la dernière réponse du fils à l'heure actuelle (miguelgrinberg du 4 avril 2015) pleine de bon sens :

Ce que les gens semble oublier, c'est que nous sommes en train de parler de systèmes gestion de ligne de commande. Il s'agit de systèmes simples dont les patterns sont connus et résolus depuis longtemps. Oui, Click a une façon originale de définir les arguments d'une ligne de commande ce qui le rend pratique et même fun à utiliser, mais au bout du compte, de mon point de vue la ligne de commande dans une application Flask est une partie extrêmement petite de mes problèmes, honnêtement ce ne fait pas de différences pour moi de devoir utiliser Click ou Flask-Script car les deux rendent la tache simple. Et Flask-Script a l'avantage d'être compatible avec argparse, ce que Click n'est pas.
[…]

Au final je vois ça comme un bel exemple de NIH, Armin est connu pour avoir créé tout un écosystème d'excellente qualité (maintenant le projet pallets) ce qui fait que les dépendances des ses projets sont presque tout le temps d'autres projets à lui (par exemple toutes les dépendances de Flask, ainsi que toutes les dépendances de ces dépendances).
Il a donc créé Click qui est un super outil, simplement dans l'écosystème Flask il existe déjà Flask-Script qui marche bien et est le standard de-facto.

S'ensuit des arguments foireux en faveur de Click sans pour autant prendre en compte ceux de Flask-Script, au hasard que ça va foutre un énorme bordel dans les extensions qui sont justement la force de Flask. On nous explique c'est in-dis-pen-sable d'avoir un module de command line livré dans Flask (c'est vrai que faire $ flask ma-commande c'est tellement mieux que $ ./manage.py ma-commande, ça justifie largement un changement majeur).
Puis une situation de pourrissement : rien ne se passe en 2 ans, le fil est abandonné depuis 1 an.
La question majeure de la migration des extensions reste en suspend et on passe l'évolution à mi-mot : le module command line est dans la release, mais ce n'est qu'un détail qu'il utilise Click.

À terme on aura donc au sein d'une même application des extensions en Flask-Script et d'autres en Click, le tout parce que l'ancienne implémentation du module d'autoreload de Flask était pas top, oui ça n'a aucun rapport…

Moi qui croyais que ce framework était un peu mou

Que Flask en lui-même n'évolue que peu me semble logique : c'est un produit à la fois simple et mature.
C'est plutôt l'activité de son écosystème (ses extensions qui le rende si modulable et puissant) qu'il faut mesurer pour avoir une idée de la vivacité du projet.

C'est même plus que sérieux : les mecs ont traduit en français les docs de leurs produits, à ce niveau ça mérite un prix de la francophonie !

Perso j'ai déjà commandé une pyboard et une wipy chez eux, aucun problème et livré rapidement.

EDIT: Je viens de me rendre compte que c'est carrément le titre du fil de commentaires…

Un des problemes que moi je rencontre avec python c'est le global lock qui fait chier sa mere pour passer sur de gros systeme et donc tu es oblige d'utiliser un autre langage pour paralleliser.

Pourrais-tu donner plus de détails sur les problèmes que te posent le gil ? De mon expérience ça se contourne facilement (y'a qu'à voir les YouTube/Dropbox qui ont des systèmes en python avec des exigences de stabilité énormes). En plus les modules de multithreading/multiprocessing sont assez bon et permettent par exemple de remplacer le threads par des processus quand on veux du calcul parallèle.

• si tu mets le même argent que pour embaucher (et en prévoyant le cout en cas de merde) une personne, tu as un service 10x mieux avec un SSSI qu'avec ton salarié, pour des raisons de mutualisation (couts, formation, gestion des maladies…)

Best. Joke. Ever.

D'après les retour que j'ai de potes, IBM facture Carrefour (qui leur sous-traite toute leur infra) de l'ordre du K€ pour chaque demande basique concernant un serveur (genre combien il reste de RAM sur un serveur donné…).

Mauvais cloud, change de cloud ;-)

Ok son message fait très "pub façon télé-achat", mais au final il présente une communauté autour d'un jeu libre ce qui a tout à fait sa place ici selon moi.

Personnellement je pense que l'article aurait gagné à adopter un schéma de type :
- présentation de mintest, historique
- différences avec minecraft le concurrent pas libre
- présentation de la communauté de jeu xorhub
- liens vers les ressources

En sortant un article de ce genre bien écrit (et en bonus pour la sortie d'une nouvelle version) l'accueil aurait été bien meilleur et serait sans doute passé en dépêche ce qui lui aurait fait gagner beaucoup en visibilité.

Merci beaucoup pour l'article, ça change d'avoir quelque chose de qualité posté un trolldi ;-)

Concernant Elm, je me pose la question de sa compatibilité avec le reste de l'écosystème javascript.
Par exemple dans la page vantant ses performances on peut voir que Elm est opposé à des frameworks web comme React, Angular plutôt qu'à d'autre "transpileurs" javascript (comme typescript ou coffeescript).

J'imagine que ça ne doit pas être simple de faire cohabiter des frameworks "mutables" avec un langage fonctionnel (ça doit être la fête à la monade…)

Comme beaucoup de moteur modernes (genre Unity ou Unreal), godot est capable de faire de la 2D ET de la 3D (exemple https://www.youtube.com/watch?v=a9zomlVEbbY, première vidéo choppée sur youtube)
De ce que les créateurs avaient annoncé au moment de la libération de Godot, celui-ci est en retard par rapport à un Unity niveau sur la 3D mais en avance sur la 2D. Et vu que beaucoup de développeurs indépendants font de la 2D, j'imagine que ça leur fait focaliser leur com' sur ce domaine.

En outre, le développement en 3D requière pas mal de middlewares payants (genre speedtree&co) et ceux-ci sont inclus via des partenariats sur les moteurs commerciaux ce que Godot ne peut pas faire en tant que produit open source. Du coup ça cantonne Godot à des projets 3D simples.

AAA ? Ce truc qui veut dire "gros budget ; pas intéressant" ?

Des jeux comme Dark Souls, The Witcher 3, ou Elite Dangerous sont des AAA et ont beaucoup plus que leur gros budget à proposer ;-)

Et sinon je pense qu'avec le passage forcé gratos à windows 10 que Microsoft à réaliser, les gens n'ont pas eu d'intérêt à changer leur OS de jeu.

Par contre je crois me souvenir que Valve a annoncé que son prochain moteur de jeu serait utilisable sans aucune royalties à condition de sortir le jeu sous SteamOS (et donc linux), ce que permet nativement le dit moteur.

Moi, avant ton edit, ça me choquait que ton commentaire ne fasse qu'une seule ligne ;)

Ma réponse va sembler simpliste mais : tu code ton appli pour qu'elle tourne sur Debian 8 et c'est tout. N'utilise pas de dépendances externes ou en version trop récente.

Personnellement ma réponse à la problèmatique est exactement inverse : installer pour chaque projet ses dépendances via le gestionnaire de la techno utilisé et ne surtout pas utiliser les paquets du système.

• Dépendances minimes du point de vu du sysadmin : l’interpréteur du langage + le gestionnaire de dépendances (bonus combo pour python 3 qui fourni CPtyhon, pip et virtualenv de série dans toutes les installations). Parfois un paquet en plus dans le cas d'un module binaire (par exemple pySSL aura besoin de libopenssl installé) mais c'est plutôt rare

• Agnostique vis-à-vis du système : la prod peut être sur Debian, les dev répartis entre Ubuntu et Mac et demain on peut migrer sur Heroku, personne n'aura de soucis

• Isolation des dépendances entre les applications : pas de risque de se retrouver avec une maj d'un dépendance pour l'application A qui casse l'application B, pas non plus de risques de se retrouver avec des dépendances implicites qui on été installées par d'autre applications

D'ailleurs en parlant d'Heroku, voir la partie dépendances de leur manifeste sur le concept de "12 factor app"