14:27 <lcaracol> bonjour
14:27 <lcaracol> je regardais le forgejo de l'afpy, je suis tombé sur une typo dans l'intitulé de ce projet:
14:27 <lcaracol> https://git.afpy.org/AFPy/pospell
14:28 <lcaracol> il manque le "r" dans la description. Pas dans le README, mais dans Forgejo
14:28 <lcaracol> après je suis pas sûr que ce soit simple à modifier
14:29 <lcaracol> """" files containing reStructuedText """
14:30 <discord_afpy> <Andy K (boss dreamer ou pas)> Salut
15:07 <discord_afpy> <grewn0uille> Hello lcaracol ! C’est updaté 🙂
15:19 <lcaracol> grewn0uille: Hello! c'est réactif par ici!
15:20 <lcaracol> au passage, j'ai regardé rapidement le site pyconfr 2025, pour l'instant j'ai pas vu de fautes
15:20 <lcaracol> il m'a l'air déjà bien prêt
15:30 <discord_afpy> <grewn0uille> Hehe, merci du check 🙂
15:43 <lcaracol> ça détend de voir des choses qui fonctionne.
15:44 <lcaracol> je sais pas si à tout hasard quelqu'un ici utilise la "ComposeKey" avec LXDE, mais ça a l'air subtil à mettre en place
15:50 <entwanne> Tu peux pas la mettre en place au niveau de Xorg ou équivalent ?
16:03 <lcaracol> entwanne: probablement. J'ai lu un paquet d'histoires plus ou moins périmées à propos de Xim, Ibus, Fcitx et Fcitx5. J'ai alors ressenti le besoin de lire autre chose
16:04 <lcaracol> sur le git.afpy, j'ai trouvé différentes manières de rédiger des pyproject.toml, je trouve ça apaisant.
16:05 <lcaracol> si quelqu'un peut me confirmer que le site https://packaging.python.org/en/latest/ est bien acceptable dans ce contexte, je vais continuer à lire autre chose
16:06 <lcaracol> moi et LXDE, on va faire une pause pendant quelques jours.
16:11 <lcaracol> au final, j'ai d'ailleurs l'impression que finalement peut de gens utilisent LXDE
16:15 <mdk> lcaracol: j'utilise la compose key depuis des lustres mais sur gnome
16:16 <mdk> lcaracol: avant d'utiliser gnome j'utilisais i3wm et pour configurer la compose key sur debian je passais par un dpkg-reconfigure keyboard-configuration, si ma mémoire est bonne
16:17 <mdk> lcaracol: oui packaging.python.org est à jour, si ton projet est très simple (un module, ou un paquet) je te conseille d'aller vers flit (`pip install flit; flit init`) puis de build avec build (`pip install build; python -m build`), puis d'upload sur pypi avec twine (`pip install twine; twine upload dist/*`), mais les autres approches sont valables aussi.
16:22 <lcaracol> mdk: je note "flit" alors, mais pour l'instant j'en suis pas encore à uploader sur Pypi, juste à regarder comment structurer un projet simple de manière moderne.
16:23 <lcaracol> ce que flit a l'air de faire pour générer le pyproject.toml
16:24 <lcaracol> par contre je remarque que pour la partie "build", la plupart des pyproject.toml que je lis restent sur
16:24 <lcaracol> build-backend = "setuptools.build_meta"
16:25 <Mindiell> ?ACTION note flit aussi sur un bout de papier...?
16:27 <lcaracol> pour en revenir à la forge git.afpy.org , j'ai l'impression que l'usage de Woodpecker a l'air de bien tourner
16:28 <lcaracol> et permettre pas mal de chose https://woodpecker.afpy.org/swagger/index.html
16:35 <lcaracol> (nb: je regarde ça à partir du dépôt de *potodo* sur la forge)
16:38 <lcaracol> (entre autres)
16:42 <lcaracol> (en aparte, le soucis que je vois avec dpkg reconfigure, c'est que ça va être probablement étendu au système, alors qu'avec un gestionnaire "qui marche" ça devrait pouvoir se régler pour chaque utilisateur. Mais c'est un détail, je vais faire une pause en attendant de voir si je croise un utilisateur de LXDE)
18:56 <lcaracol> au passage, il y a un comportement marrant de pip-compile.
18:57 <lcaracol> dans ce projet *potodo* , le requirements.txt généré par pip-compile https://git.afpy.org/AFPy/potodo/src/branch/main/requirements.txt
18:57 <lcaracol> annonce trouver les dépendances dans le setup.py . Dans un projet qui utilise pyproject.toml
18:58 <lcaracol> comme quoi, rien n'est parfait
19:18 <lcaracol> ...
19:19 <lcaracol> en tous cas, d'après ce que je lis en complément, ce woodpecker semble valoir largement autant que le 'forgejo actions' comme choix pour la CI
21:31 <mdk> lcaracol: je n'ai jamais testé "forgejo actions", merci pour ton retour :) on a fait le choix de woodpecker avant la naissance de "gitea actions".
21:31 <mdk> lcaracol: côté flit vs setuptools, tu peux passer de l'un a l'autre extrêmement simplement. Que j'utilse flit ou setuptools j'utilise `python -m build` pour build. Et que j'utilise flit ou setuptools j'utilise `twine` pour l'upload sur PyPI. J'aime les outils qui ne font qu'une seule chose et qui le font bien ;)
21:38 <discord_afpy> <fred.et.rick> je ne connais pas Flit. c’est un build backend à l’image de setuptools et hatchling ?
22:07 <mdk> fred.et.rick, oui, mais KISS
22:07 <mdk> il ne fonctionne que sur des projets très simples, mais justement j'aime les outils simples
22:08 <mdk> le nombre de lignes de code de flit par rapport au nombre de lignes de code de hatch, setuptools, poetry, uv, pipenv, et companie. Sachant que le nombre de bugs répond à E=MC² (errors = (more code)²), je me dis qu'il y a moins de bugs qui peuvent se cacher dans flit ;)
22:15 <discord_afpy> <fred.et.rick> oui, de ce que j’ai cru comprendre, Hatch se veux être plus que juste un build backend, mais je ne l’ai pas testé pour autre chose que ça
22:17 <discord_afpy> <fred.et.rick> après plus de code, de mon point de vue, c’est pas tellement plus de bug le pb, c’est plus de temps pour comprendre le projet et être capable de proposer un fix si tu trouve un bug. Mais du coup je te rejoint, plus simple c’est pas plus mal