00:49 <debnet> Faudra que je me renseigne sur ce lockfile, à la première lecture j'ai pas trop compris l'utilité.
00:56 <alain_afpy> Questions, idées d'améliorations et quelques petits trucs - https://discuss.afpy.org/t/questions-idees-dameliorations-et-quelques-petits-trucs/2545
01:37 <discord_afpy> <saturn7694> une très bonne chose ce lockfile
07:09 <Mindiell> la meilleure chose c'est de décider d'un truc, oui
08:27 <entwanne> Perso j'ai peur que ça mène à ce que les gens freezent trop précisément leurs versions sans trop de raison, mais c'était déjà le cas avec la pléthore d'outils fonctionnant sur ce principe. Il n'est pas nécessaire de reproduire l'environnement de production (mêmes versions précises des dépendances) partout où on installe un projet…
09:28 <discord_afpy> <naoyfurieux> En effet, ça dépend de ce qu'on publie, mais pour du web, c'est quand même très pratique de profiter d'un lockfile (même si requierement.txt fesait très bien le taf amha)
09:44 <entwanne> j'aime pas trop le fait de mélanger ça avec le code, pour moi les dépendances fixes (le lockfile) dépendent de l'environnement et non du code en lui-même, qui devrait pouvoir tourner (et être déployé) avec différentes versions des dépendances
11:11 <discord_afpy> <Dorian TURBA - remote> il me semble que c'est l'objectif des `requirements.in`
11:12 <discord_afpy> <Dorian TURBA - remote> Par exemple, avoir un `requirements.in`, un `dev-requirements.in`, etc
11:12 <discord_afpy> <Dorian TURBA - remote> `pip-compile` et tu as un lock file `requirement.txt` ou `dev-requirement.txt` pour chaque env
11:13 <discord_afpy> <Dorian TURBA - remote> cependant je n'utilise plus ça depuis que j'ai migré sur UV
11:13 <discord_afpy> <Dorian TURBA - remote> (quoi que même sans uv, ça fonctionnait aussi avec le pyproject.toml, c'est ce qui m'a permis de facilité la migration d'ailleurs)
11:14 <discord_afpy> <Dorian TURBA - remote> tu mets les dépendances principales dans le `pyproject.toml` (avec les optionelles, de dev, etc)
11:14 <discord_afpy> <Dorian TURBA - remote> et uv se charge de faire le lock-file
11:26 <entwanne> Oui bien sûr, mais j'ai l'impression que ça force des dépendances fixes à des endroits où ce ne serait pas nécessaire (dans le dev)
11:52 <alain_afpy> Sur Lyon − Jeudi Programmation de l’ALDIL le 3 avril - https://discuss.afpy.org/t/sur-lyon-jeudi-programmation-de-l-aldil-le-3-avril/2548
12:25 <discord_afpy> <naoyfurieux> je vois pas vraiment le rapport avec le code, c'est juste que lorsque tu fais du web,
12:27 <discord_afpy> <naoyfurieux> donc fixer les dependance pour que les tests / la recette / la prod tournent avec les même version des deps est plutôt cool
12:27 <discord_afpy> <naoyfurieux> si les environnement de dev ont les même versions, c'est pas plus mal
12:29 <discord_afpy> <naoyfurieux> et la distinction requierment.in / requirement.txt est super pour ça, parce que même si le code «devrait» fonctionner avec les future versions (indiquée dans requierement.in) on «sait» qu'il tourne avec celle du requierment.txt
12:29 <discord_afpy> <naoyfurieux> ça évite les soucis, certes rares, (mais déjà vécu) de la maj de version de dep entre les test et la mise en prod
12:30 <entwanne> c'est bien de pouvoir reproduire les versions des dépendances de tel ou tel environnement, oui, ça ne me paraît par contre pas souhaitable d'imposer ces versions par défaut pour tout environnement
12:32 <discord_afpy> <fred.et.rick> pour moi ça serait plutôt l’inverse, ça ne me parait pas souhaitable d’avoir des versions différentes des dépendances en fonction de l’environnement. c’est un coup à avoir des "ça marche sur ma machine"
12:32 <discord_afpy> <fred.et.rick> ou des "oui, la prod est en train de bruler, mais ça marche en staging"
12:35 <entwanne> Si le code doit être déployé sur un environnement, il doit être aussi testé pour cette enviropnnement (donc avec les dépendances de cet environnement)
12:36 <entwanne> le cas que tu présentes me paraît d'ailleurs souhaitable, ça aide à identifier d'où provient l'erreur rencontrée
12:36 <discord_afpy> <eyecontrol> Et avec une bonne CICD (avec un env de test identique à la prod) pour la mise en prod, on pourrait avoir différents env.
12:36 <discord_afpy> <eyecontrol> Puisqu'on testerait le code envoyé en prod en amont
12:37 <entwanne> et je vois plein de cas légitimes pour avoir des versions différentes suivant les environnements : tester une montée de version majeure d'une dépendance avant la mise en prod, dépendre d'un gestionnaire de paquets autres (par exemple construire un paquet deb pour installer le projet) avec ses propres dépendances, installer un même projet pour différents clients avec des besoins différents
12:38 <asyd> :q
12:38 <asyd> oups
12:39 <discord_afpy> <fred.et.rick> entwanne: le fait que certains projet ne doivent pas utiliser de lockfile ne me semble pas remettre en question le besoin d’un lockfile normalisé
12:42 <discord_afpy> <chadys> et puis typiquement le lockfile, ça se met à jour, tu le mets à jour en local d'abord, pour tester les montées de version, puis en staging puis en prod, en utilisant le même fichier versionné.
12:42 <discord_afpy> <chadys> Pour différents client j'aurais tendance à avoir des dossiers de build multiple, un par client, avec chacun son lockfile
12:42 <discord_afpy> <fred.et.rick> d’ailleurs, si tu veux créer un paquet Debian pour ton application, c’est les dépendances Debian que tu vas utiliser, donc le lockfile ne vas même pas être utilisé
12:42 <discord_afpy> <Dorian TURBA - remote> Normalement dans le dev, uv sync et tu as des dep lache
12:43 <discord_afpy> <fred.et.rick> encore faut il utiliser uv
12:44 <discord_afpy> <Dorian TURBA - remote> C’est pareil avec pip-compile
12:44 <discord_afpy> <Dorian TURBA - remote> Uv a juste integré les fonctionnailté de pip-tools
12:44 <discord_afpy> <Dorian TURBA - remote> Pip install . Et tu as des dep lache basé sur ton pyproject.toml
12:44 <discord_afpy> <Dorian TURBA - remote> J’ai fais ça pendant des années avang uv
12:46 <entwanne> fred.et.rick : et je ne remets pas en cause cette PEP, je suis pour les lockfiles, je n'aime juste pas qu'ils soient packagés avec le projet plutôt qu'à l'extérieur (et je me demande si une telle normalisation ne va pas amener des gens à en utiliser là où ce ne serait pas nécessaire)
12:47 <misc> bah, c'est pour que le dev dise "j'ai tenté avec tel version", non ?
12:47 <entwanne> perso ce qui me fait peur serait qu'on arrive à un stade où les librairies seraient distribuées avec des versions de dépendances tellement strictes que ça deviendrait un enfer à utiliser
12:48 <misc> bah, ça devient un enfer quand tu as 2 sources différentes pour les libs
12:48 <misc> genre pip et ta distro
12:49 <discord_afpy> <Dorian TURBA - remote> 100% d’accord ! Penser que fix les versions est une bonne pratique pour une lib publique, c’est se tirer une balle dans le pied
12:49 <discord_afpy> <Dorian TURBA - remote> Je parle evidement de les fix dans les dependances de pyproject.toml ou .in
12:50 <discord_afpy> <Dorian TURBA - remote> Le lock pour moi sert a "garantir" des tests pour un set de version bien spécifique.
12:50 <discord_afpy> <Dorian TURBA - remote> Pour préparer la’prod par exemple
12:53 <entwanne> misc: Non mais même si j'utilise pip, je ne veux pas que la lib tartampion m'impose pouet==1.3.6 tandis que la lib carbonade voudrait pouet==1.3.7, j'ai "peur" que la standardisation/généralisation des lockfiles mène à de tels cas
13:10 <discord_afpy> <Dorian TURBA - remote> C’est ce que je dis
13:11 <discord_afpy> <Dorian TURBA - remote> Ah
13:11 <discord_afpy> <Dorian TURBA - remote> J’ai rien dis j’avais mal lu
13:20 <misc> entwanne: mais dans ce cas, la CI upstream va le voir, non ?
13:22 <entwanne> Oui, ça va planter, et ensuite je fais quoi ? À part demander aux mainteneurs des projets en question de gérer leurs versions plus souplement, ou les forker pour les maintenir de mon côté, je ne vois pas trop d'issue
13:29 <misc> ben, ça
13:45 <discord_afpy> <saturn7694> les versions des paquets trop strictes c'est déjà possible à faire avec un requirements ou dans le setup.py, mais c'est rarement le cas parce que les gens qui développe des paquets python le font pas . non seulement parce qu'ils savent ce qu'ils font en général et si un le fait il se prend vite un ticket pour lui demander d'être moins stricte.
13:45 <misc> en fait, je pense que de base, le souci va arriver pour tout le monde, donc il y a des chances que ça se régle tout seul
13:46 <discord_afpy> <saturn7694> je dis pas que ça arrive jamais. Mais souvent c'est pour une bonne raison (genre un breaking change pas intégré)
13:48 <discord_afpy> <fred.et.rick> entwanne: je suis forcé d’admettre que j’ai du mal à voir l’interet d’un lock file qui ne ferait pas parti du code de l’application au même titre que le pyproject. Si le lock file est exterieur, je ne vois pas comment garantir que ce qui tourne dans la CI c’est ce qui tourne sur mon poste, à moins de build mes conteneurs sur mon poste et de les pousser sur la CI au lieux de pousser le code… j’ai pas trop envie de
13:53 <discord_afpy> <saturn7694> Oui et en plus on peut utiliser des branches différentes pour tester les upgrades, les différents environnements etc...
13:54 <entwanne> perso j'ai pas forcément envie que la CI reproduise mon poste, plutôt qu'elle reproduise les différents environnements que je cible, et donc je ne vois pas la nécessité à ce que ce soit couplé au code, ça peut être un projet à côté qui fournisse le lockfile et sur lequel est lancé une CI
13:55 <discord_afpy> <fred.et.rick> la CI n’est pas la pour reproduire mon poste, c’est mon poste qui est la pour reproduire la prod le plus fidèlement possible
13:55 <discord_afpy> <fred.et.rick> hors, sans lockfile, c’est mort
13:56 <discord_afpy> <saturn7694> oui au mieux parfois c'est pas possible et c'est pour ça qu'on a des CI entre autres
13:57 <discord_afpy> <saturn7694> pour éviter le "ça marchait sur mon poste"
13:57 <discord_afpy> <fred.et.rick> d’où le "le plus fidèlement possible"
13:57 <entwanne> ben si tu veux que ton poste local reproduise les versions épinglées d'un environnement précis, tu peux en effet installer depuis le lockfile conçu pour cet environnement, ce n'est pas pour autant que ça a besoin d'être packagé ensemble
13:58 <discord_afpy> <eyecontrol> Ce que je ne comprends pas dans votre discussion, ce lockfile est necessaire si on a une CI bien configurée ?
13:58 <discord_afpy> <saturn7694> d'où le "oui"
13:58 <discord_afpy> <saturn7694> c'est un plus oui
13:58 <entwanne> je raisonne vraiment en faisant la distinction entre développement du code et déploiement, en imaginant que le code/projet produit pourrait être utilisé/déployé par différentes équipes à différents endroits, et que c'est aux mainteneurs (ceux qui déploient) de fixer leurs versions pour leur environnement
13:59 <discord_afpy> <saturn7694> après ça dépend de comment tu veux organiser tes repos, ta ci etc...
13:59 <entwanne> Et globalement mon avis plus détaillé rejoint celui-ci : https://discuss.afpy.org/t/pipenv-pourquoi-faire/654/3?u=entwanne
13:59 <discord_afpy> <saturn7694> en ce moment on est plus monorepo quand même
14:01 <discord_afpy> <saturn7694> Si tu fais de la presta ou tu livres la même déclinaison d'une app adaptée au client ça peut justifier des repos différents par client.
14:02 <discord_afpy> <fred.et.rick> ah oui, alors que je raisonne en voulant le plus de garanti possible qu’il n’y aura si possible pas de "ça marche sur mon poste" et que les mainteneurs fournissent une recette pour build le conteneur, les devs la liste des packages validés pour fonctionner entre eux
14:03 <entwanne> eyecontrol: Pour moi il est "nécessaire" de fixer strictement les versions d'un environnement pour pouvoir contrôler les montées en version (éviter d'être surpris), mais dans un monde idéal si la CI couvre tout ça ne doit en effet pas casser
14:03 <discord_afpy> <fred.et.rick> c’est tellement relou de debug un truc que t’arrive pas à reproduire en local que j’ai pas envie de faire ça, dutout
14:03 <discord_afpy> <saturn7694> bon ça dépend beaucoup de ce qu'on fait. En général pour beaucoup on est sur une seule appli web qui tourne sur un serveur.
14:03 <discord_afpy> <saturn7694> un ou plusieurs serveurs...
14:04 <discord_afpy> <fred.et.rick> perso j’ai plusieurs appli qui tournent sur un serveur, mais je ne vois pas ce que ça change
14:04 <entwanne> mais si t'as plusieurs environnements qui existent (staging, prod) que tu ne déploies pas au même instant (et il y a nédessairement un moment où les deux ne sont pas alignés) il te faut de toute façon plusieurs instances locales pour représentes les différents ensembles de dépendances distants, donc je ne vois pas quel est le problème
14:04 <entwanne> `source env-prod/bin/activate` et hop
14:05 <entwanne> (je ne vois pas trop non plus dans quel cas "ça marche sur mon poste" serait une excuse valide pour quoi que ce soit, par contre il faut que ça marche sur la CI qui cible les différents environnements)
14:05 <alain_afpy> WARNING !!! YAKAFOKON DETECTED !!!!
14:05 <discord_afpy> <saturn7694> rien ce qui change (et ça arrive) c'est le boites de presta qui décline une même app chez plusieurs clients. c'est la merde à la fin on s'y retrouve plus mais ça existe
14:06 <discord_afpy> <saturn7694> oui mais c'est pas un souci parce que tu es sur deux branches différentes
14:07 <entwanne> pas nécessairement si le code du projet ne change pas
14:07 <discord_afpy> <saturn7694> "ça marche sur mon poste" ça justifie de tester l'appli dans un environnement neutre : la CI
14:08 <discord_afpy> <saturn7694> tu parles du staging/prod entwanne ?
14:08 <entwanne> Oui par exemple, ou de tout ensemble de 2 environnements distincts qui peuvent potentiellement avoir des dépendances précises différentes à un instant t
14:09 <discord_afpy> <saturn7694> prod c'est l'état N et le staging l'état N+1 donc si on fait des monté en version le nouveau lock file avec les nouvelles deps et dans la branche staging
14:09 <discord_afpy> <saturn7694> quand c'est bon on merge et on passe en prod
14:09 <entwanne> dans mon cas hypothétique le lockfile n'est pas intégré au projet, il est géré à part, par environnement
14:10 <discord_afpy> <saturn7694> c'est un peu se compliquer la vie mais ça peut se justifier
14:10 <entwanne> pour moi c'est se compliquer la vie que d'imposer des lockfiles partout :D
14:10 <discord_afpy> <fred.et.rick> > il te faut de toute façon plusieurs instances locales pour représentes les différents ensembles de dépendances distants
14:10 <discord_afpy> <fred.et.rick> ben non, justement, une fois l’ensemble futur validé, il ne tourne que sur un seul environnement, donc j’ai pas besoin d’avoir les différentes versions des dépendances
14:10 <discord_afpy> <saturn7694> *le nouveau lock file avec les nouvelles deps est dans la branche staging
14:11 <entwanne> mais l'ensemble futur n'est pas forcément l'ensemble actuel (celui qui tourne aujourd'hui en prod), donc si tu veux reproduire un bug lié à des dépendances qui survient aujourd'hui en production, il faudra de toute façon adopter les dépendances de l'environnement de production
14:11 <discord_afpy> <saturn7694> ce que tu dis ça peut se justifier si tu as plusieurs clients avec des environnements / des besoins spécifique, des versions différentes de ton app etc...
14:12 <discord_afpy> <saturn7694> pour que ce soit pas trop le bazard dans ton app
14:12 <entwanne> je trouve ça plus sain de considérer que c'est toujours le cas
14:12 <discord_afpy> <saturn7694> mais même là c'est la merde. il faut pas faire ça...
14:12 <discord_afpy> <fred.et.rick> franchement, on a ça (bon, en php, mais c’est pareil, osef), on se fait pas chier, on a un projet core, un dossier par client et roulez jeunesse
14:13 <discord_afpy> <saturn7694> oui si c'est bien fait pourquoi pas ...
14:13 <discord_afpy> <saturn7694> mais c'est galère
14:13 <discord_afpy> <saturn7694> faut bien gérer
14:14 <discord_afpy> <fred.et.rick> > il faudra de toute façon adopter les dépendances de l'environnement de production
14:14 <discord_afpy> <fred.et.rick> le jour où ça arrive à cause d’un pb de dépendance, y’a juste utiliser l’image de prod
14:17 <discord_afpy> <saturn7694> pour moi le staging sert précisément à ça. c'est une copie conforme de la prod, avec les data backup de la prod. ça sert à voir si tout fonctionne correctement.
14:19 <discord_afpy> <fred.et.rick> chez nous c’est une copie conforme de la prod avec quelques commit d’avance quand même, donc effectivement, des fois, t’as un bug en prod qui n’apparait pas ailleurs parce que le code ou les dépendances on déjà changé entre temps
14:19 <discord_afpy> <saturn7694> ah bien sûr comme je disais c'est l'état N+1 . L'état souhaité à la fin du processus.
14:21 <discord_afpy> <saturn7694> > les dépendances on déjà changé entre temps
14:21 <discord_afpy> <saturn7694> c'est pour ça que les lock file c'est bien, voir les images dockers.
14:21 <entwanne> Et on se rejoint là-dessus, le seul point sur lequel on diffère concerne l'endroit où l'on fixe les dépendances. Je vois le projet (le code) comme "pur" et agnostique de l'environnement sur lequel il va tourner, tout comme il n'est pas pollué par la configuration nécessaire pour tel ou tel environnement (qui change aussi, on ne déploie pas les secrets de prod ailleurs)
14:23 <discord_afpy> <saturn7694> ça dépend du mode de distribution, si c'est destiné à tourner sur plusieurs environnement (genre une app mobile, un clietn lourd etc) oui. Mais la plupart du temps on déploie une appli django sur un serveur. C'est quand même le gros des usages.
14:24 <entwanne> ça n'empêche pas de concevoir la chose ainsi
14:24 <discord_afpy> <saturn7694> oui mais je vois pas l'intérêt de faire ça dans ce cas.
14:25 <discord_afpy> <saturn7694> tu as qu'une seule prod dans ce cas.
14:27 <discord_afpy> <fred.et.rick> > Je vois le projet (le code) comme "pur" et agnostique de l'environnement sur lequel il va tourner
14:27 <discord_afpy> <fred.et.rick> ça me semble assez utopiste, à moins, soit de ne pas utiliser de dépendances, soit de fixer les dépendances avec lesquelles il vient
14:28 <discord_afpy> <fred.et.rick> surtout je vois le dev comme responsable de livrer une application fonctionne, ce qui ne peut pas être le cas si les ops s’amusent à mettre leurs gros doigts dans les dépendances du projet
14:29 <entwanne> saturn7694 : l'intérêt c'est une séparation claire des responsabilités, la détection de certains problèmes en amont (comme la CI du projet n'est pas figée sur l'environnement de prod, elle peut détecter tout de suite des bugs qui se produiront avec une montée de version mineur d'une dépendance)
14:30 <discord_afpy> <saturn7694> après si tu fais une application destiné à tourner sur toutes les distri linux du monde, tu as un truc bien packagés destiné à être adapté et configurable . Tu es assez souple sur les dépendances l'application puisse s'adapter au pquet sytèmes et au pire les mainteneurs patche
14:30 <entwanne> fred.et.rick : le projet a des dépendances, mais elles sont définies de façon souple (Django==5.*) et non strictes (Django==5.1.7)
14:31 <entwanne> le dev s'assure, en fixant sa dépendance sur Django==5.* que le projet fonctionne effectivement pour toutes les versions 5.* de Django.
14:31 <entwanne> Le mainteneur lui fixe la version précise qu'il veut déployer sur tel ou tel environnement
14:32 <misc> mais si le projet n'est pas testé avec tout les deps, c'est quand même un peu contre l'idée :/
14:32 <discord_afpy> <fred.et.rick> je n’arrive pas à trouver du sens à cette façon de fonctionner, ça oblige à faire le boulot 2 fois, voire plus
14:33 <entwanne> (le mainteneur, en épinglant les dépendances, choisit un sous-ensemble des versions sur lequel le dev promet que le projet fonctionne)
14:33 <discord_afpy> <saturn7694> tu vois tu dis "tel ou tel environnement" ça c'est vrai quand tu distribue ton app.
14:34 <entwanne> mais vous dites vous aussi avoir des environnements de staging et de production qui peuvent avoir des versions de dépendances différentes, donc c'est vrai pour vous (et c'est sans compter l'environnement local en cours de développement quand on ajoute une nouvelle dépendance)
14:34 <discord_afpy> <fred.et.rick> plus, ça veux dire que le dev doit s’assurer que toutes les versions passent les tests, alors qu’il n’y aura en fait qu’une seule version qui tournera dans le conteneur de prod, jusqu’à la prochaine mise à jour des dépendances
14:34 <discord_afpy> <fred.et.rick> c’est une perte d’efficacité folle
14:35 <entwanne> selon moi ça permet de prévenir des bugs (ça ne fonctionne pas par chance parce que tel comportement interne de telle dépendance fonctionne ainsi en version 1.2.3 mais pas en 1.2.4) donc ce n'est pas une perte d'efficacité, au contraire
14:35 <discord_afpy> <saturn7694> c'est un peu ce que fait circle ci... mais je pense qu'on parle pas de la même chose. c'est pas le même job de faire tourner une appli web qu'une appli linux par exemple. Mais ce dernier sujet à toujours été un sujet difficile.
14:37 <discord_afpy> <saturn7694> c'est pour ça qu'il il a des ditri des gestionnaire de paquet "atomic" etc...
14:38 <discord_afpy> <fred.et.rick> à quoi bon prévenir des bugs qui pourraient ne jamais arriver, soit parce que l’application passera de 1.2.3 à 1.2.5 directement, soit parce que la dépendance aura été viré d’ici là et qui seront de toute façon attrapé par la CI lors de la monté de version ?
14:38 <entwanne> Justement, le travail de maintenance d'une distribution pour fixer les paquets compatibles n'est pas le même que celui de développer les paquets
14:39 <discord_afpy> <saturn7694> oui c'est pour ça je pense qu'on parle pas de la même chose
14:39 <discord_afpy> <saturn7694> mais c'est un vaste sujet ça...
14:39 <discord_afpy> <fred.et.rick> et sourtout, comment garantir que l’application est compatible avec toutes les versions 2.* de pydantic alors qu’elles ne sont pas toutes encore sorti ?
14:40 <entwanne> Je crois qu'on parle précisément de la même chose, dans tous les cas il s'agit de programmes (Python pour ce qui nous intéresse) qui tournent sur des machines
14:41 <discord_afpy> <saturn7694> sur une machine dans notre cas c'est toute la différence. Il n'y a aucune raison que le serveur change (enfin pas tous les 4 matins)
14:41 <entwanne> il y a plusieurs serveurs, et des machines locales qui entrent en compte dans le processus de développement
14:41 <discord_afpy> <saturn7694> oui ça c'est pas la même chose.
14:41 <entwanne> fred.et.rick : ça sert principalement à détecter le problème plus tôt (dès qu'une version 1.2.4 de la dépendance existe par exemple) plutôt que tard (quand on choisit de passer tous les environnements sur la version 1.2.5)
14:42 <entwanne> saturn7694 : la seule différence c'est que tu contrôles les machines sur lesquelles ton programme tourne
14:42 <discord_afpy> <saturn7694> dans le cas d'une application web la prod reste la même sauf MAJ système et ça on se concerte avec les devs/adminsys/devops, et accessoirement on utilise des conteneurs
14:44 <Mindiell> saturn7694: c'est vrai pour une appli non distribuée
14:44 <discord_afpy> <saturn7694> oui
14:44 <Mindiell> pas pour une apli distribuée, je préfère fixer perso
14:44 <discord_afpy> <saturn7694> c'est ce que je depuid tout à l'heure en fait
14:45 <discord_afpy> <saturn7694> et encore les applis distribués la tendances et à la standardisation car c'est beaucoup de travail.
14:45 <entwanne> et on est tous d'accord là-dessus (fixer les versions pour un environnent précis)
14:46 <discord_afpy> <saturn7694> c'est juste que quand tu en as qu'un tu as un fichier lock avec ton code et ça roule tout seul
14:46 <entwanne> personnellement je trouve ça sale
14:47 <Mindiell> quand tu n'as qu'un quoi ? Qu'est-ce qui est sale ?
14:47 <discord_afpy> <saturn7694> ça fait gagner du temps.
14:48 <discord_afpy> <saturn7694> qu'un environnement de prod Mindiell
14:49 <entwanne> Sale de distribuer les versions épinglées avec le code du projet, plutôt que de les fournir à côté avec la configuration liée à l'environnement
14:49 <Mindiell> je dois pas avoir le niveau. Pour moi, le lockfile sert justement à n'avoir qu'un seul environnement (je parle de l'environnement python, pas tout le reste)
14:49 <Mindiell> entwanne: ah je veux bien savoir pourquoi, je trouve ça mieux moi :oD
14:49 <discord_afpy> <saturn7694> oui c'est tout le sujet
14:50 <entwanne> Mindiell: je viens d'en parler pendant plusieurs heures donc ça va faire beaucoup de redite
14:51 <entwanne> Mindiell: mon avis est "résumé" ici https://zestedesavoir.com/billets/4637/do-not-use-requirements-txt/ et identique à https://discuss.afpy.org/t/pipenv-pourquoi-faire/654/3
14:53 <entwanne> (et le souhait de n'avoir qu'un environnement est utopique, même dans un monde où tu n'aurais pas de CI ni de serveur staging/test/pré-prod, il y aurait toujours un laps de temps où il peut y avoir une différence entre l'env local et l'env de prod, notamment quand tu fais des montées de versions)
14:54 <misc> c'est aussi l'idée derriére les deploiements dans des conteneurs, non ?
14:54 <Mindiell> ah ben en dev, forcément, c'est là que tu peux mettre à jour. Je lirai ton bille,t merci o/
14:54 <misc> (ensuite, oui, le cout d'entrée est parfois conséquent (/me regarde la facture AWS de son openshift a vide)
14:55 <discord_afpy> <saturn7694> c'est marrant parce que dans ton article tu sembles bien faire la distinction
14:55 <discord_afpy> <chadys> Perso ça me semble logique de versionner ensemble lock et code, justement dans le cas d'une montée de version : tu mets à jour le lock, tu mets à jour le code (si nécessaire) pour garder la compatibilité avec les nouvelles version/profiter des nouveautés, et les deux arriveront en même temps sur le serveur de prod
14:56 <discord_afpy> <saturn7694> c'est quoi la différence entre staging et préprod j'ai jamais compris ceux qui font la distinction...
14:57 <discord_afpy> <chadys> chez nous staging et préprod (et aussi qa pour "quality assurance") c'est la même chose
14:58 <discord_afpy> <saturn7694> oui surtout que bien souvent ils en font rien de leur staging les gens... à mon grand désaroi...
14:59 <entwanne> chadys : je pense que c'est surtout une question "philosophique", de mon côté je considère dans tous les cas qu'un projet peut un jour avoir vocation à être distribué (projet open-source) ou déployé à différents endroits dans des conditions différentes, et donc que les conditions en question n'ont pas être encodées avec le projet
15:00 <entwanne> saturn7694 : dans certains cas ça peut être que staging n'a pas d'utilisateurs externes alors que pré-prod est accessible à des clients qui peuvent l'utiliser comme une bêta par exemple, et donc les deux environnements n'ont pas la même charge et la même fiabilité (c'est "ok" de casser un environnement qui n'est pas accessible aux clients)
15:00 <discord_afpy> <saturn7694> oui mais toutes les apps open source fixe leur dépedances heureusement d'ailleurs. pas de manière stricte mais elles le font.
15:00 <discord_afpy> <saturn7694> si tu dépends de lib-xml2 tu dépends d'un certains range de version
15:01 <discord_afpy> <chadys> je comprend mais faire un code compatible avec plusieurs versions de dépendances à la fois, c'est clairement pas la même charge de travail et à notre niveau absolument pas envisageable (et je vois pas le gain). On parle évidemment d'application toujours, pas de bibliothèque ou là c'est évidemment souhaitable
15:01 <entwanne> décrire les dépendances (Django==5.0, foobar>=2 && <4) et les épingler (Django==5.1.7, foobar=2.8.0) sont deux choses différentes
15:01 <discord_afpy> <saturn7694> ah oui c'est la recette du coup
15:02 <entwanne> (je voulais bien sûr écrire "Django==5.*" et non "Django==5.0")
15:02 <discord_afpy> <saturn7694> oui effectivement dans ce cas précis les fichier lock ne servent pas
15:03 <discord_afpy> <saturn7694> les locks files c'est bien quand tu es plusieurs devs sur une seule app avec un seul déploiement.
15:03 <entwanne> comme évoqué pour moi le gain c'est d'avoir quelque chose de plus propre (ne pas mélanger les responsabilités), ne pas se retrouver bloqué à cause de ça ensuite (car le code sera nativement conçu pour pouvoir tourner sur différents environnements), détecter en amont des problèmes liées à des montées de dépendances
15:04 <discord_afpy> <chadys> nous on épingle que des versions précises pour toutes les dépendances, si tu veux utiliser d'autres versions, à toi de maintenir le code pour t'assurer que ça fonctionnera avec et donc tu sors du cadre de ce qu'on met à disposition. Donc dans cette démarche notre code est complétement dépendant des versions de dépendances fixés, donc versionné avec
15:04 <discord_afpy> <saturn7694> oui je suis pas sûr que tui détecte tout mais je comprends
15:05 <discord_afpy> <chadys> et dans cette démarche, c'est le dev qui est responsable des dépendances, c'est donc lui qui livre le fichier de recette et qui test
15:07 <discord_afpy> <chadys> si on voulait pouvoir être multiversion, ce serait juste beaucoup plus de boulot, sans aucun gain notable (dans mon contexte)
15:08 <discord_afpy> <saturn7694> sachant que 90% du temps aujourd'hui les applications c'est des interfaces devant une API c'est des problématique moins courantes. Mais quand on vise l'open source effectivement il faut pas tout figer. Parce qu'au final c'est le mainteneur qui va packager ça pour sa distri.
15:09 <discord_afpy> <chadys> ben on a tout figé quand même :p
15:09 <discord_afpy> <saturn7694> vous distribuez votre appli en open source sur Linux ?
15:09 <discord_afpy> <chadys> à nous pas sur linux
15:09 <discord_afpy> <chadys> **non
15:10 <entwanne> ouais je comprends, et c'est aussi ce qui me fait peur avec la standardisation des lockfiles, que ça se répande parce que c'est jugé plus facile et que en gros "il suffit de faire tourner le truc dans docker pour ne pas avoir de conflits de dépendances avec l'OS" :D
15:11 <misc> bah c'est clairement ça
15:11 <discord_afpy> <saturn7694> tu sais quand même que tous les gros projets open source ils offrent une version dockerisé de leur app (postgres, mysql, nginx, etc...)
15:11 <discord_afpy> <chadys> tout dépend du type d'appli que tu dév et des problématiques associé, de mon côté je ne parle que du point de vue d'une appli web opensource. Aucune raison de faire un package natif du bordel
15:11 <misc> et en fait, du point de vue de l'upstream, c'est malheureusement assez indispensable sauf à tester avec 15 distros
15:12 <discord_afpy> <saturn7694> oui c'est le sujet Chadys, ç'est pas pareil
15:13 <entwanne> saturn7694 : je sais et je trouve ça pratique dans certains cas, ça n'empêche pas que l'application soit utilisable sans
15:13 <discord_afpy> <saturn7694> ce que je veux dire c'est que en tout cas dans le monde des serveurs c'est déjàç en route depuis un moment déjà.
15:15 <entwanne> c'est une manière de faire mais ce n'est pas la seule, les outils en question sont bien souvent aussi packagés
15:16 <misc> ensuite, tu peux aussi juste retirer le lockfile et basta
15:16 <misc> je l'ai fait souvent pour ruby (non sans avoir de souci, mais bon)
15:16 <discord_afpy> <saturn7694> perso j'ai connu les serveurs que plus aucun admin ne veuillent mettre à jour par peur de casser ce qui tourne dessus. Donc c'est du boulot quand même.
15:18 <discord_afpy> <saturn7694> les sytèmes de type apt et rpm sont sur leur fin.ça existe encore un peu mais ç'est pas l'avenir.
15:18 <misc> j'ai des doutes
15:18 <misc> deja, les images immutables, on continue à faire ça avec rpm
15:19 <misc> ensuite, je vois mal les vendeurs de softs refaire le tooling pour les 25 types de languages alors que l'Europe et d'autres demandent d'avoir plus d'info sur ce qui tourne, etc (CRA, etc)
15:19 <misc> on a vu par exemple avec log4j ce que ça a donné avec java et le bundling :/
15:19 <discord_afpy> <saturn7694> ah oui c'est toujours du rpm pour redhat, mais c'est plus les maj habituelle
15:21 <discord_afpy> <saturn7694> non mais je suis d'accord que si on distribue une app python il faut pas épingler
15:21 <misc> ça dépend qui distribue en fait
15:21 <misc> et comment est fait la mise à jour
15:22 <misc> et ce qu'on distribue aussi
15:22 <discord_afpy> <saturn7694> c'est quoi qui dépend ?
15:22 <misc> bah, de locker ou pas
15:23 <discord_afpy> <saturn7694> oui au pire les mainteneurs adaptent (ils le font tout le temps en fait...=
15:23 <misc> si je distribue une lib, c'est pas pareil qu'une application qui est pas pareil qu'un site web, si je fait un truc pour un service que je déploie , c'est pas pareil que de l'auto hebergement pur des tierces personnes
15:24 <misc> et c'est pas pareil si je controle l'os ou pas, etc, etc
15:24 <discord_afpy> <saturn7694> en fait c'est un problème de langage interprété parce que pour les compiler de toute façons faudra faire le build
15:24 <discord_afpy> <saturn7694> oui c'est un pezu ce que je disais tout à l'heure ça
15:25 <entwanne> les programmes compilés dépendent souvent aussi de libs dynamiques qui doivent elle aussi être installées (et le gestionnaire de paquets résoud ces problèmes)
15:25 <discord_afpy> <saturn7694> ah bon pas programmes python ?
15:25 <discord_afpy> <saturn7694> libpq, libxml pour les plus célèbres...
15:26 <entwanne> ben si, d'où le "aussi", tu avais l'air de dire que ce n'était pas le cas pour les programmes compilés
15:26 <misc> y a parfois aussi des gens qui font le choix de rester uniquement dans un ecosystéme specifique
15:26 <misc> (genre, je tente de rester 100% rust quand je peux)
15:26 <discord_afpy> <saturn7694> je disais aue c'était encore plus problématique en fait
15:27 <discord_afpy> <saturn7694> car tu le vois a l'exécution
15:27 <misc> mais si tu dépend de lib en C, tu peux pas locker spécifiquement
15:27 <misc> au plus, tu as le numero du .so
15:27 <misc> enfin, si tu peux voir la version au configure
15:27 <discord_afpy> <saturn7694> si ton programme est fixer sur une version spécifique d'un paquet python que la ditri n'a pas encore
15:28 <discord_afpy> <saturn7694> oui c chiant...
15:28 <misc> ça arrive tout le temps ça
15:29 <discord_afpy> <saturn7694> ça arrive au dev qui font le bootstrap du projet, pas tous...
15:30 <discord_afpy> <saturn7694> je vaux dire pour les paquets "système" pour les lib python il y a les virtualenv
15:31 <discord_afpy> <saturn7694> mais en fait on parlait des app open source qui sont packagé par les distri. Si c'est déployé une app sur un serveur c'est pas pareil.
15:37 <discord_afpy> <saturn7694> bon je résume: si tu déploie sur une seul environnement genre une appli web, une api web, là c'est utile d'avoir un lock des versions parce que ça permet d'avoir une cohérence entre lles envs de dev/testing/staging/prod. Mais si tu déploies ton app sur des environnements hétéroclites, genre sur Linux, windows, des mobiles ches des serveurs de clients etc... là tu laisse plus de libertés au client sur le choix des dépendanc