09:34 <grenoya> bonjour
09:48 <mdk> bonjour
10:32 <misc> coin
10:33 <feth> angle
10:39 <feth> C'est beau, ce site pycon fr
10:52 <gawel> ouaip
12:10 <zmo> o/
12:11 <zmo> gawel - t'utilises toujours buildout ?
12:26 <gawel> oui
12:30 <jpcw> zmo: il y aurait quoi d'autre ?
12:31 <zmo> ♥
12:32 <zmo> pas beaucoup de gens qui apprécient buildout
12:32 <zmo> https://github.com/guyzmo/buildstrap
12:32 <zmo> pour arrêter de fabriquer à la main des buildout.cfg pour les projets faits pour virtualenv
12:33 <zmo> (j'ai eu un coup de ras le cul hier)
12:34 <jpcw> """While most of the python community tried to keep up, and got their shell configuration or global pip changing regularly, some have been quietly enjoying python development the same way for the last ten years, using buildout for their development."""
12:34 <jpcw> so true !
12:34 <zmo> en fait j'ai essayé hier matin de le faire « selon les règles de l'art »
12:35 <jpcw> zmo: perso je crache mes buildouts avec un template
12:36 <zmo> donc j'ai d'abord fait un virtualenv: ça m'a pêté mon prompt, j'ai essayé de corriger mon prompt, après 30 min à faire du zshrc au lieu de coder, (et mis à jour pour utiliser antigen donc tout n'est pas perdu) j'ai arrêté et ai décidé d'utiliser pyenv et pyvenv
12:36 <zmo> là ça a marché, pour me rendre compte que ça m'a pêté pip sur tous mes terms, pas juste dans celui où je codais, j'ai essayé de comprendre le problème… puis finalement j'ai fait un buildout.cfg comme d'hab
12:37 <zmo> puis je me suis dit qu'il devrait yavoir moyen d'automatiser le fait de créer un buildout.cfg pour arrêter d'utiliser un copy/paste d'un template ou d'un précédent projet
12:38 <zmo> (parce qu'utiliser un template, ça va pour démarrer un projet, mais quand on hacke sur un biniou pour juste faire un patch…)
12:40 <zmo> donc bref, j'ai fait buildstrap, et si ça vous plaît → issues/PR je suis pas forcément convaincu de l'interface CLI telle qu'elle est, ya peut-être moyen de l'améliorer et d'apporter plus de flexibilité sur la génération (notamment par exemple utiliser un template type jinja pour que chacun puisse générer son buildout.cfg selon ses goûts?)
13:21 <sveetch> zmo: tu serais pas en train de recréer cookiecutters un peu ?
13:22 <sveetch> bon en un peu plus spécialisé
13:48 <zmo> sveetch - pas vraiment, le but est pas de créer un template pour démarrer un projet, le but est de remplacer machin-env pour n'importe quel projet en utilisant buildout
13:49 <sveetch> ah ok
13:49 <zmo> en gros, si je veux hacker requests, j'ai qu'à faire un `buildstrap run requests requirements.txt` et ça va générer un buildout.cfg et lancer buildout
13:49 <zmo> ensuite j'ai direct bin/py.test accessible, et bin/python -c 'import requests' utilisable
13:50 <zmo> pour l'instant le buildout généré est fait "en dur" sans configurabilité (i.e.: faut sortir l'éditeur pour le mettre à son goût)
13:51 <zmo> donc peut-être qu'un outil comme cookiecutter pourrait servir à choisir une base de template pour générer le buildout.cfg
13:52 <sveetch> hmmmm
13:53 <zmo> en fait, j'ai presque pas réfléchi à la question de la personnalisation du biniou, pour moi c'est surtout un moyen de faire des buildout.cfg jetables
13:53 <sveetch> zmo: je lui donne n'importe quelle package sur github et il me monte un buildout ?
13:53 <zmo> TBH, j'irais presque à farfouiller un peu plus dans le code de buildout et lui filer l'équivalent dict() de la conf buildout sans générer de fichier
13:53 <sveetch> ah non ça dépend d'un requirements.txt quand meme
13:54 <zmo> c'est pour n'importe quel package conçu avec des requirements.txt, donc conçus pour être utilisés avec virutalenv et consors
13:54 <sveetch> zmo: pas eu le courage de parser les requirements d'un setup.py ? :)
13:57 <zmo> sveetch - beh, c'est un choix de design: le setup.py donne une « classe » de compatibilité pour les packages, le requirements un freeze
13:57 <zmo> c'est pour la même raison qu'il y a une sorte de redondance aussi dans le buildout.cfg sur les listes d'eggs
13:57 <zmo> cf https://caremad.io/2013/07/setup-vs-requirement/
13:59 <zmo> le principe étant qu'avec un requirements.txt tu donnes des versions statiques pour le dev (genre des versions fixes, ou une référence vers le fork d'une lib avec une branche qui ajoute une feature ou fix un bug spécifique)
13:59 <zmo> c'est ce que le gus appelle une dépendence « concrète »
13:59 <sveetch> ouais enfin le buildout l'optique c le déploiement fonctionnel, tu peux te contenter des dépendances direct au projet et le laisser récupérer les dépendances tierces au mieux, bon après y'a les conflits entre packages
14:01 <zmo> alors que dans le setup.py tu donnes juste les dépendences abstraites, les versions n'étant que par classes. En gros tu devrais jamais faire une dépendance ==1.0.0 dans le setup.py mais >=1.0.0…
14:01 <sveetch> ouais
14:01 <sveetch> ...
14:01 <sveetch> en théorie :)
14:01 <feth> sachant que l'API de la v2 kaboum
14:02 <sveetch> feth: v2 de Pypi ? le truc qu'on attends depuis 3ans ?
14:02 <feth> version 2.0.0 de "dépendance"
14:02 <sveetch> ah
14:02 <zmo> >=1.0.0,<2.0.0 :)
14:02 <feth> pour bien faire, j'imagine qu'on pourrait faire un paquet "plop_API" qui gèrerait cette histoire de dépendance dans ses requirements
14:02 <No`> >=1.0.1,<2.0.0,!=meuh
14:02 <sveetch> pour peu que tu tournes pas sur un pip < 1.4
14:03 <zmo> après rien ne m'empècherai d'ajouter le support de setup.py dans buildstrap pour générer le parts avec les deps
14:03 <zmo> empècherait*
14:03 <zmo> pour les projets qui n'ont ni requirements.txt ni buildout.cfg, juste un setup.py
14:03 <feth> zmo: perso je ne fais pas de setup.py en ce moment
14:04 <feth> euh, pas de requirements.txt
14:04 <feth> juste des setup.py
14:04 <feth> (et précisément là, je digère)
14:04 <sveetch> perso je me repose toujours sur le setup.py, je laisse le requirements_**.txt pour les environnement de devs
14:04 <zmo> tu fais des buildout.cfg ?
14:04 <zmo> mais le but de buildstrap c'est de faire des env de dev (et éventuellement plus, à la discrétion de l'user)
14:06 <sveetch> mais pour faire un env de dev d'une app django/flask/etc.. il faut lui monter un mini project django pré configuré, je connais pas de recipe buildout qui fasse cela correctement
14:08 <zmo> perso je fais que du flask et créer un env de dev c'est simple… sinon j'évite le django tant que possible (j'ai toujours trouvé le framework overengineeré), donc je connais pas trop le problème de la phase de setup
16:04 <alain_afpy> matin
21:03 <zmo> qqun utilise ici remarkdown avec sphinx pour la doc ?
21:03 <zmo> je veux dire recommonmark