 Bonsoir, je continue la série des Personnels Demands, je vais faire une série de portraits pour présenter des personnes importantes de la communauté. Aujourd'hui, donc Donald Stoft, quelqu'un qui est peut-être pas connu mais qui fait beaucoup de travail en coulisses, fait partie d'un certain nombre d'équipes, une équipe qui s'appelle Python Cryptography Authority, c'est un des développeurs de PIP, également de Django, fait partie de Python Packaging Authority. Donc ça, c'est des teams qui sont hors de Python Core et puis du côté officiel de Python, il y a un administrateur de PIPI, le Package Index, de l'équipe d'infrastructure qui va maintenir Python.org, bugs.python.org, les mailing lists ainsi de suite, et puis le Python Security Response Team. Peut-être que tout le monde n'est pas au courant, les bugs de sécurité qui exposent des failles éventuellement dans les applications, on évite de les signaler sur le tracker de bugs publics, mais pratiquement tous les projets en mailing list ou un système séparé qui permet de résoudre ces problèmes, communiquer avec les personnes qui pourraient être affectées avant que ce soit public. Dans l'équipe Python, c'est une mailing list, comme la plupart des choses, qui permet de traiter ces problèmes-là. Ce qui est intéressant avec Donald Stoft, il faisait du PHP à l'époque, disait un CMS, Drupal, puis se trouvait limité, il est passé à Django, comme beaucoup d'entre vous, entre nous, et de là, il s'est mis à faire du Python pratiquement tout le temps, il travaille actuellement chez Rackspace. Ce qui est intéressant, c'est l'histoire de cette équipe-là. Au début, il y avait des distuités d'un bibliothèque standard, puis à côté, on avait Ease install de setup2s, on a eu PIP ensuite, qui fonctionnait avec, mais qui corrige Ease install. On a eu Virtual Env, qui propose un système d'isolation, mais Build Out, qui a une philosophie totalement différente. Il y avait 15 équipes différentes créées sur le packaging. Et un jour, sur GitHub, pour consolider les dépôts de plusieurs projets, ils ont créé ce nom d'équipe, qui s'appelait Python Packaging Authority, mais qui était un peu l'autorité de facto, c'était les mainteneurs de PIP et de Virtual Env, qui étaient totalement déconnectés de Python Dev, le groupe officiel qui développe Python et le packaging officiel. Et il se trouve que depuis, il y a Nick Coglan, qui est un core développeur, un des plus actifs, qui a pris sur lui de pousser une nouvelle série de PEP en avant pour améliorer le packaging, en partant de l'installation de PIPI jusqu'à l'autre bout de la chaîne, construire un paquet, donc compiler ses sources Python ou C. Et du coup, cette team est devenue finalement officielle. On a eu comme ça, c'était un nom qui était un peu une joke, qui aurait peut-être même pu, non seulement déplaire à des personnes, disant, mais comment ils peuvent s'appeler l'autorité, ce n'est pas du tout officiel. Et finalement, c'est un groupe de personnes qui travaillent ensemble de la documentation officielle à Setup Tools, à PIP, à Virtual Env, afin d'améliorer le packaging pour tout le monde. Donc c'est pour ça que j'ai mis à la frontière, c'est une team non officielle officielle de Python. Nombre de choses qu'il y a participé. Il y avait 2 mailing lists principalement pour packaging Python. Il y avait Catalog CIG, CIG étant Special Interest Group, et Distutile CIG, qui ont été fusionnés cette année. Des choses discutées qu'ont été implémentées. Le stockage de Modpast, ça va être amélioré pour qu'il ne soit plus en clair dans la base de données mais chiffré. Ça a été fait quand il y a eu un compromis de la base de données du wikipiton. SSL, on a eu un certificat propre qui n'était pas autosigné pour PIPI, et puis les outils, clients étaient modifiés pour le vérifier. Il y a un CDN qui a été ajouté à PIPI pour servir tous les fichiers statiques, de façon plus efficace que l'ancien système de miroir. Les miroirs existent toujours. Il y a toujours des clients comme Banner Snatch qui permettent de faire votre propre miroir pour votre compagnie. Mais l'idée est que la communauté aurait un ensemble de miroirs qui avaient des noms comme A, point PIPI, point Python, point Org. Ça, c'est le côté de protocole d'autodécouverte qui a été supprimé. Ce qui est intéressant avec Donald, c'est qu'il a plusieurs traits de caractère qu'on voit à différents endroits. Selon vous regardez sur GitHub ou Twitter ou les mailing lists, des fois, il va être vraiment énervé. Le nom de son site, c'est Kermad. C'est comme malade de chagrin et c'est quelqu'un qui va être vraiment attristé de voir l'état de déploiement du packaging ou de la cryptographie. Et ce qui est intéressant, c'est qu'il peut très bien, comme nous, être humain et s'énerver sur Twitter et puis ensuite transformer ça en énergie positive, proposer des changements concrets. Sur credit.io, il a mis en place beaucoup de changements qui ont été depuis acceptés dans Pipe.io même. Il y a une PEP qui a été faite, qui évite que quand on tape, PIP installe quelque chose, il y ait la moitié des pages de source-forge qui soient scrapées par du code de setup tools pour trouver c'est quoi le terminal qu'on va télécharger. En plus d'autres personnes ont poussé pour qu'il y ait directement les fichiers donc des releases hébergés sur Pipe.io. Dans le futur, on va utiliser un projet tiers, on lui dirait inventé, qui s'appelle the update framework pour résoudre le problème de signature entre le développeur qui crée un paquet et la personne qui veut l'installer. Je passe rapidement, vous aurez la vidéo, comme mon temps se termine. Comme développeur de PIP, il participe aussi au côté client des changements. Il a participé à PIP 453 qui fait que dans Python 3.4 qui sort d'ici Python, PIP pourra être disponible de base et comme depuis Python 3.3, on a des virtuos à l'envee dans le texte standard, on pourra finalement, j'installe Python, je peux tout de suite créer un virtuos à l'envee et j'ai dedans un installeur de paquet. Et dans le futur, on a aussi packaging cette table 2.0 qui va encore améliorer la gestion des dépendances, spécifier séparément dépendances facultatives, dépendances nécessaires, dépendances de tests, et ainsi de suite. Juste donner quelques citations. Ce qu'il préfère dans Python, c'est le fait que l'engage soit expressif sans qu'il utilise toutes les ponctuations possibles au point que ce soit illisible. Et ce qu'il aime le moins, c'est d'habiter standard. Certains des paquets les plus téléchargés de Pipe.io sont des remplacements par l'un des textes standards. Beaucoup de modules datent d'une époque où on faisait moins attention à ce qu'il y a en train de mettre un texte standard et c'est dommage, beaucoup de personnes les utilisent et vous connaissez toute la différence entre URL libre et request. Il y en a qui est beaucoup plus pratique que l'autre, beaucoup plus moderne. Dans la communauté, il trouve que c'est vraiment dommage, c'est les mailing lists qui ont pas mal d'hostilité, toujours le fameux bike-shading, dont je parlais au mois de décembre, les gens qui vont débattre sur un détail au lieu de se mettre d'accord sur le fond du problème. Par contre, hors des mailing lists, il trouve que la communauté est vraiment accueillante, il y a du support pour toutes les idées et que c'est des très bonnes personnes avec lesquelles travailler. Je vais demander comment imaginer l'avenir et comme vous pouvez le lire, il voudrait vraiment qu'on puisse dire à un moment qu'en Python pour les développeurs, on a un système de packaging qui répond aux besoins et simplement qui fonctionne. C'est un des plus gros points de trouble aujourd'hui en Python. Merci.