09:12 <gawel> matin
10:05 <Genesis> bonjour
10:28 <kujiu> bonjour
12:38 <gawel> (un afpyro à l'arrache)
13:28 <yotaff> pq, c'est différent d'habitude ? :>
13:36 <gawel> gnagnagna
13:43 <tarek> oui c'est différent, il l'annonce vers 17h d'habitude
13:57 <yotaff> quelle est la bonne méthode pour wrapper une classe non zope3 en composant z3
13:57 <yotaff> ?
13:57 <yotaff> enfin la c'est une fonction qui renvoie une classe
13:57 <tarek> elle fait quoi ta classe ?
13:57 <yotaff> c'est la classe logger de python
13:58 <yotaff> on voudrait le transformer en composant z3 afin de pouvoir choisir une implémentation de log
13:58 <tarek> tu veux faire quoi ?
13:58 <yotaff> en faire un utility
13:58 <tarek> c a d, pour faire des logs "maison" ?
13:58 <yotaff> c'est un objet utilisable partout, donc le foutre dans une registry et appelable par n'importe qui
13:58 <yotaff> oui
13:58 <yotaff> à la base j'ai codé un wrapper
13:59 <tarek> mmm je ferais pas ca,
13:59 <tarek> en fait il suffit d'utliser logging directement dans ton appli zope
13:59 <tarek> et derrière d'ecrire un hook dans zconfig
13:59 <yotaff> c'est du python pur la
13:59 <tarek> ben oui car zope utilise logging directement
13:59 <yotaff> mais on code par défaut en z.i & z.c
14:00 <tarek> c'est quoi z.i & z.c ?
14:00 <yotaff> zope.interface
14:00 <yotaff> zope.component
14:00 <tarek> ah...
14:01 <tarek> si tu veux gerer un systeme de log de plus haut niveau dans zope, fait un utility pkoi pas,
14:01 <tarek> mais seulement si dedans tu fait qq chose de plus que logging en AMONT de zope
14:01 <tarek> sinon tu écris un hook pour zconfig
14:02 <tarek> mais au final dans ton utility, appel logging
14:03 <yotaff> en réflechissant non, faut pas le faire
14:03 <yotaff> en gros l'interface c'est pour les objets métiers
14:03 <yotaff> pas les objets techniques
14:04 <tarek> un utility rend un service, mais pour le logging dans zope on est passé d'un outil proprio (zLOG) à celui de python, qui est synchronisé à la conf via zconfig, qui lui permet de programmer des plugins
14:05 <yotaff> ce n'est *pas* dans zope la :)
14:05 <tarek> donc un utility de log c'est si et seulement si tu a besoin d'y chopper des infos dans le context de zope, différentes de ce que le logging de base te fournirait
14:06 <tarek> ah tu veux créer un outil de log, générique ?
14:06 <yotaff> oui, car on a un père qui lance des fils
14:06 <yotaff> chacun log (le père, les fils)
14:07 <yotaff> donc je réfléchis à une stratégie
14:07 <tarek> un père ? un processus père ?
14:07 <yotaff> donc une utility,c'est élégant
14:07 <yotaff> oui
14:08 <tarek> logging est bien foutu pour ca, si je me souviens bien c'est thread safe si tu veux que tous ecrivent dans un meme fichier de log
14:08 <tarek> il suffit de brancher la sorti pour .warning, .info, .error, etc
14:08 <tarek> je pense que t'a deja tout
14:10 <No`> salut les afpystes
14:10 <tarek> salut No
14:36 <gawel> yotaff: sinon tu peux logger dans syslog
14:36 <gawel> y a des handler pour ça
14:36 <gawel> a mon avis c'est le plus clean / secure
17:09 <yotaff> tarek: on en est ou des index multiples dans setuptools / buildout ?
17:24 <tarek> yotaff j'ai écrit un patch, j'attend du feeback de Eby
17:24 <tarek> donc d'ici 2/3 mois :D
17:25 <tarek> si tu veux le tester...
17:27 <yotaff> faut que je teste aussi la gestion de mercurial
17:27 <yotaff> on va surement passer dans 1 mois
17:30 <tarek> ouai c cool le patch mercurial !
17:39 <gawel> mercurial est supporté par setuptools ?
17:41 <tarek> y a un patch
17:41 <tarek> du coup y aura plus besoin d'ecrire le manifest
17:41 <tarek> entres autres
17:41 <gawel> j'ai jamais cherché a savoir a quoi ca servait :p
17:42 <tarek> ben si t'ecris pas le manifest.in,
17:42 <tarek> avec svn il te construit le sdist comme il faut
17:42 <tarek> mais si t'a pas de .svn
17:42 <tarek> il va prendre un pattern par défaut
17:43 <tarek> et du coup tes distribs peuvent etre foireuses
17:43 <tarek> fichier .txt qui manque etc
17:43 <tarek> me suis fait avoir
17:44 <gawel> voilà pourquoi j'ai jamais eu à m'en soucier
17:45 <gawel> c'est le find_packages qui est un peu moisis en gros non ?
17:48 <tarek> ouai, il scrute .svn
17:48 <tarek> apres je sais pas comment il faut avec mercurial vu que le .hg est pas forcément dans le dossier
17:49 <tarek> mais je dirais que le plus simple est de pondre un MANIFEST.in correct
17:49 <tarek> dans les templates
17:49 <tarek> c pas dur
17:49 <yotaff> moi ce qui m'intéresse c'est le hg_revision
17:49 <gawel> ouais, t'inclus tout :D
17:49 <yotaff> pour le marquage des eggs
17:51 <gawel> y aura moyen de faire une install depuis une url hg aussi ?
17:57 <tarek> gawel, yes je crois
17:57 <tarek> c la feature la plus important pour moi
17:57 <tarek> c bien pratique
17:58 <gawel> clair
17:59 <tarek> vous avez vu les stats comparatives mercurial/bzr sur le trunk de python .
17:59 <tarek> ?
17:59 <tarek> en gros mercurial ets bcp plus rapide que bzr
17:59 <No`> teu teu teu
17:59 <cyberj> \o/
17:59 <cyberj> envoie :)
18:00 <No`> t'oublies une loi importante : http://www.sharms.org/blog/?p=196
18:01 <tarek> haha
18:01 <No`> tarek: moi aussi je trouve hg plus rapide que bzr. J'utilise bzr quand j'ai envie/besoin d'un projet publié sous Launchpad
18:01 <No`> (ex : beeroverip)
18:01 <tarek> a oui voila
18:01 <tarek> http://pyside.blogspot.com/2008/08/quick-hgbzr-timings.html
18:02 <tarek> apres les stats c'est toujours discutable
18:02 <tarek> mais bon
18:02 <cyberj> tarek: merci
18:02 <tarek> vu que je suis pro-mercurial, j'aime bien ce genre de posts ;)
18:02 <No`> tarek: discutable, d'où la loi énoncée par Harms
18:02 <tarek> yup
18:03 <No`> lancer de troll, catégorie DCVS... "et git ?"
18:03 <tarek> oui voila j'allais le dire
18:03 <tarek> mais tout ca est une saine concurrence
18:03 <tarek> pour avoir la peau à svn/cvs
18:04 <No`> cvs?... quel dinosaure l'utilise encore ?
18:05 <No`> bon, allez... la trappiste n'attend pas
18:05 <tarek> drupal je crois
18:05 <tarek> en meme temps qd tu vois le logo de drupal
18:06 <tarek> c'est trop bleu
18:06 <tarek> trop bleu tout ca
18:06 <cyberj> boh ça va encore
18:06 <tarek> oui je troll :)
18:08 <cyberj> Ouais ok le bleu fait PHP... ET ALORS?
18:08 <cyberj> remarque le bleu y'en a dans le logo python
18:09 <tarek> c'est pas du bleu, c'est du marine légèrement ambré
18:10 <cyberj> C'est quand même un bleu suffisant pour faire avec le jaune (lui aussi suffisant) du vert
18:10 <tarek> ouai
18:11 <cyberj> Tu t'emmerderai pas un peu pour sortir des trolls pareils?
18:12 <tarek> lol
18:12 <tarek> je suis dans une phase de transition
18:12 <cyberj> :)
18:13 <tarek> j'ai fini un truc, j'en ai 4 milliards à démarrer, donc je trouve que cette discussion tombe à point nommé pour procrastriner
18:14 <cyberj> Alors pour ma culture, je suppose que c'est voulu cet assemblage de bleu et jaune qui ferai du vert si les deux "serpents" n'étaient pas séparés
18:14 <cyberj> non?
18:15 <tarek> j'y avait jamai pensé !
18:15 <tarek> s
18:15 <tarek> c surement ca
18:39 <tarek> http://pyworks.mtacon.com/c/schedule/talk/d1s5/3
19:29 <yotaff> 4go le Pypi
19:29 <yotaff> ca va, ca reste raisonnable