Posté par YBoy360 (site web personnel) .
Évalué à 3.
Dernière modification le 24 septembre 2022 à 12:45.
J'enrage aussi beaucoup contre Gradle, mais au final c'est un outil de dingue.
Juste un point :
Même configurés à fond de leurs capacités, les meilleurs IDE n’ont pas les moyens de donner des conseils pertinents.
Dans le cas de Gradle, il n'y a pas de support de l'IDE (du moins elle est empirique comme tu l'indiques), car les DLS statiquement typés de Groovy sont apparus après. La version Kotlin est statiquement typée de ce que j'en comprends (j'utilise très peu kotlin dans Gradle).
Pas mal des points que tu soulèves dépendent de ce problème, mais globalement je suis d'accord avec toi, tout système de build t'impose un cadre et des conventions, Gradle est gavé de conventions pas toujours claires, pour nos projets, ça pose bien des soucis.
Cela dit, lorsque l'on respecte ces conventions, on gagne finalement du temps. On peut aussi créer des extensions simplement, donc l'exotisme du build d'un projet particulier est un problème solvable selon moi, d'autant plus que les plugins Gradle récents sont faciles à lire (peut-être pas tous, mais c'est ce que j'ai constaté d'une manière générale).
Et le fait de respecter des conventions facilite le partage.
Pouvoir sur n'importe qu'elle OS, sans avoir a installer d'autres dépendances que Java faire :
Toute la complexité est masquée derrière une syntaxe et des « outils » qui se veulent simples.
La partie masquée de la complexité est rendue artificiellement inaccessible, parce que les API mises à disposition sont trop partielles et n’ont pas de points d’extension :
Même configurés à fond de leurs capacités, les meilleurs IDE n’ont pas les moyens de donner des conseils pertinents.
On doit donc se reposer entièrement sur la documentation, qui est souvent mauvaise.
La notion même de DSL rends complexe le lien entre une déclaration et le code exécuté – ce qui empêche l’exploration pour savoir ce qui va être fait exactement.
On peut mettre du code arbitraire ou presque, mais le debug est impossible (notamment les points d’arrêt).
Rien n’est typé et la syntaxe est trop libérale, on découvre toutes les typo au runtime.
Comme le DSL masque la complexité, plus personne ne comprends ce qui se passe réellement2. Conséquence : les plugins sont d’une qualité catastrophique et conçus pour ne gérer que le cas précis de la personne qui les a développés – or ces plugins sont indispensables.
Pire : les documentations pour développer (ou aider à la maintenance) des plugins sont elles-mêmes mauvaises, ce qui empire le phénomène.
Tout ce que tu décrit au choix :
marche aussi bien pour l'utilisation de langages déclaratifs (1, 2, 4, 5, 8)
n'ont rien d'intrinsèque à l'utilisation d'un langage impératif (7, 9)
le typage est très dépendant du langage que tu choisi (7)
je ne vois pas beaucoup d'outil véritablement aider pour le 3, par exemple netbeans est le seul outil à faire une intégration poussée de maven, les gens se contente très bien d'intelij qui a une intégration à peu près équivalente pour maven et gradle
Le seul point qui reste c'est d'avoir du code que tu ne peux pas facilement debugger. La solution est toute trouvée c'est de ne pas fournir un outil qui se configure via un DSL, mais une bibliothèque que tu utilise dans le build que tu implémente. C'est comme ça que fonctionne le gestionnaire de fenêtre xmonad par exemple.
Personnellement je trouve qu'il y a infiniment plus de valeur à avoir un build simple qui ne cherche pas à triturer pleins de choses parce que "tu comprends mon projet il est différent de tous les autres donc je vais pas me contenter de faire comme tout le monde" et je pense que si un outil de build passe à se paradigme ça va donner des builds infernaux à maintenir dans le temps et à comprendre.
Note qu’au moins une configuration par langage déclaratif ne te promet pas de pouvoir exécuter du code arbitraire, à effort égal ça force un système mieux documenté et plus complet. Les DSL, eux, se retrouvent avec beaucoup de « solutions » qui sont du type « utilise ce bout de code dégueu qui fait approximativement ce que tu demandes », et le problème d’origine n’est jamais résolu.
Pour le build simple, je suis d’accord en théorie. Sauf qu’on ne bosse pas uniquement sur des projets récents et/ou dont on a maitrisé l’architecture de A à Z. En fait, je pense même que le problème source de ce genre d’outils est précisément là : ils sont conçus pour ce cas de build simple où tu rentres très exactement dans les cases prévues, mais pas pour la vie réelle où tu as des cas plus complexes sur lesquels tu n’as pas la main.
[…] ils sont conçus pour ce cas de build simple où tu rentres très exactement dans les cases prévues, mais pas pour la vie réelle où tu as des cas plus complexes sur lesquels tu n’as pas la main.
Ça demande une certaine mauvaise fois ou à minima un haut niveau d’exagération d'affirmer ça quand on voit un maven qui a était conçu pour normaliser à fond les builds et qui a rencontré un gros succès. Cette même normalisation d'ailleurs sur la quelle s'appuient gradle/sbt/ant+ivy pour ne pas avoir à réinventer la roue.
Je ne dis pas que l'inverse n'existe pas, mais affirmer que « dans la vie réelle » les conventions ça marche pas et tu dois tweaker c'est y aller fort.
Après c'est toujours pareil, les softs qui continuent de tourner en Java5, de compiler qu'avec gcc 2.92, d'utiliser une interface XUL,… personne n'a envi de payer leur dette à leur place. Ça peut être vu comme une forme de jeunisme, mais c'est aussi une question de ne pas ossifier les technologies.
Tu déformes mon propos et tu réponds à la déformation, on ne va pas aller loin comme ça.
Le problème des « cases » n'est pas « les vieilles technologies ». D'ailleurs le pire pom.xml que j'ai croisé (près de 10 000 – dix mille – lignes était un projet qui avait quatre ans, en Java 11, et qui respectait la structure habituelle des projets Maven.
Non, quand je parle de « cases » qui sont trop petites et qui nécessitent des contournements, il ne faut pas aller chercher loin. Par exemple, avoir trois dépôts Docker séparés pour les builds snapshot / release / nightly.
Tu déformes mon propos et tu réponds à la déformation, on ne va pas aller loin comme ça.
Le problème des « cases » n'est pas « les vieilles technologies ».
Ce n'était pas ma volonté, mais quand j'entends « projet sur le quel on a pas la main » c'est généralement pour expliquer que la dette technique elle est chère etc.
D'ailleurs le pire pom.xml que j'ai croisé (près de 10 000 – dix mille – lignes était un projet qui avait quatre ans, en Java 11, et qui respectait la structure habituelle des projets Maven.
Je ne vois pas comment c'est expliquable (autrement que par de l'incompétence1). Donne leur le build tool que tu veux ils feront n'importe quoi avec. D'ailleurs être en mesure de sortir ça avec maven, ça me fait peur d'imaginer ce que ça pourrait donner avec gradle.
Non, quand je parle de « cases » qui sont trop petites et qui nécessitent des contournements, il ne faut pas aller chercher loin. Par exemple, avoir trois dépôts Docker séparés pour les builds snapshot / release / nightly.
On gère ça avec une properties dockerRepository qu'on set comme on le souhaite. On a pas de nightly, mais dev par défaut, qlf on surcharge via la CLI et release c'est reset dans un completion goal du release prepare. Ça convient peut être pas chez vous.
je veux pas être particulièrement insultant le projet fait peut être des choses très bien au demeurant. C'est juste que je ne vois pas comment ça peut arriver autrement que sans comprendre maven ou en essayant de lui tordre le bras vraiment fort. ↩
Ce n'était pas ma volonté, mais quand j'entends « projet sur le quel on a pas la main » c'est généralement pour expliquer que la dette technique elle est chère etc.
Je ne parle pas de projet sur lesquels on a pas la main mais de cas sur lesquels on a pas la main. C’est plus général que le simple projet, ça implique des règles internes à l’entreprise, etc.
Je ne vois pas comment c'est expliquable (autrement que par de l'incompétence1). Donne leur le build tool que tu veux ils feront n'importe quoi avec. D'ailleurs être en mesure de sortir ça avec maven, ça me fait peur d'imaginer ce que ça pourrait donner avec gradle.
C’était un exemple pour te montrer que « n’importe quoi » n’implique pas « vieux projet » ou « technologies pourries », et réciproquement. Et oui, ce truc est débile et impossible à maintenir en l’état.
On gère ça avec une properties dockerRepository qu'on set comme on le souhaite. On a pas de nightly, mais dev par défaut, qlf on surcharge via la CLI et release c'est reset dans un completion goal du release prepare. Ça convient peut être pas chez vous.
Là encore, fais des suppositions, puis tu tires des conclusions à partir des suppositions que tu as tirées – qui sont donc fausses. D’une part le problème n’est pas l’URL du dépôt mais l’identification ; d’autre part ça concerne Jenkins et pas Docker, donc « une properties » n’est pas une solution utilisable (en tous cas pas de façon simple sans dupliquer une tâche).
Là encore, fais des suppositions, puis tu tires des conclusions à partir des suppositions que tu as tirées – qui sont donc fausses.
J'ai décris comment moi j'ai fais et fini en disant que ça ne suffit peut être pas pour tout le monde. On arrivait à le faire aussi avec jenkins via les secrets.
Je ne dis pas que tu ne rencontre pas de problème, mais que dire que dès que tu es multi-dépôts ça ne marche pas c'est faux. Ils ne gèrent probablement pas tous les cas (j'imagine par exemple que selon le runtime que tu utilise ça va coincer), ça pourrait être plus simple, ça pourrait être mieux géré (jenkins en soit est relou à ustiliser).
mais que dire que dès que tu es multi-dépôts ça ne marche pas c'est faux
Encore une fois, tu inventes un élément et tu réponds à cet élément. Mon propos, c’est qu’on doit bidouiller, pas que « ça ne marche pas ».
Ici, j’ai dû bidouiller parce que mon besoin ne rentrait pas dans les cases prévues : le plugin ne peut s’authentifier qu’à un seul dépôt (et crée un fichier de configuration dédié, donc enchâsser les configurations l’une dans l’autre ne fonctionne pas). Il y bien un plugin qui le permet, mais c’est pas celui qui est installé sur le serveur Jenkins et qu’on utilise pour tout le reste. Et c’est pas un plugin exotique, hein, c’est les standards.
Mais en fait on s’en fout, c’est qu’un exemple. Je ne viens pas ici pour demander comment faire ce truc en particulier.
Alors oui, dans un monde parfait, théorique et tout, je me serais contenté d’utiliser le plugin qui va bien dans Jenkins et tout aurait été parfait, doux et rose. Mais justement, on est pas dans un monde théorique et je dois composer avec des contraintes extérieures. Et c’est précisément là que le bât blesse : trop souvent ces outils de configuration par DSL partent du principe que tu es en Théorie, ne sont pas conçus pour gérer autre chose, et dès que tu t’en éloignes c’est l’enfer.
Et ça n’est pas la peine de venir expliquer qu’il suffit de changer d’outil ou de rentrer dans une configuration « standard » : le problème est précisément quand on ne peut pas faire ce genre de chose, quelle qu’en soit la raison.
# Vive Autoconf
Posté par YBoy360 (site web personnel) . Évalué à 3. Dernière modification le 24 septembre 2022 à 12:45.
J'enrage aussi beaucoup contre Gradle, mais au final c'est un outil de dingue.
Juste un point :
Dans le cas de Gradle, il n'y a pas de support de l'IDE (du moins elle est empirique comme tu l'indiques), car les DLS statiquement typés de Groovy sont apparus après. La version Kotlin est statiquement typée de ce que j'en comprends (j'utilise très peu kotlin dans Gradle).
Pas mal des points que tu soulèves dépendent de ce problème, mais globalement je suis d'accord avec toi, tout système de build t'impose un cadre et des conventions, Gradle est gavé de conventions pas toujours claires, pour nos projets, ça pose bien des soucis.
Cela dit, lorsque l'on respecte ces conventions, on gagne finalement du temps. On peut aussi créer des extensions simplement, donc l'exotisme du build d'un projet particulier est un problème solvable selon moi, d'autant plus que les plugins Gradle récents sont faciles à lire (peut-être pas tous, mais c'est ce que j'ai constaté d'une manière générale).
Et le fait de respecter des conventions facilite le partage.
Pouvoir sur n'importe qu'elle OS, sans avoir a installer d'autres dépendances que Java faire :
Élimine bien des critiques (AMHA)..
# configuration par DSL
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Je ne sais pas pourquoi j'ai cru que tu allais nous parler de Puppet/Chef/etc.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Bof
Posté par barmic 🦦 . Évalué à 3.
Tout ce que tu décrit au choix :
Le seul point qui reste c'est d'avoir du code que tu ne peux pas facilement debugger. La solution est toute trouvée c'est de ne pas fournir un outil qui se configure via un DSL, mais une bibliothèque que tu utilise dans le build que tu implémente. C'est comme ça que fonctionne le gestionnaire de fenêtre xmonad par exemple.
Personnellement je trouve qu'il y a infiniment plus de valeur à avoir un build simple qui ne cherche pas à triturer pleins de choses parce que "tu comprends mon projet il est différent de tous les autres donc je vais pas me contenter de faire comme tout le monde" et je pense que si un outil de build passe à se paradigme ça va donner des builds infernaux à maintenir dans le temps et à comprendre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bof
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Note qu’au moins une configuration par langage déclaratif ne te promet pas de pouvoir exécuter du code arbitraire, à effort égal ça force un système mieux documenté et plus complet. Les DSL, eux, se retrouvent avec beaucoup de « solutions » qui sont du type « utilise ce bout de code dégueu qui fait approximativement ce que tu demandes », et le problème d’origine n’est jamais résolu.
Pour le build simple, je suis d’accord en théorie. Sauf qu’on ne bosse pas uniquement sur des projets récents et/ou dont on a maitrisé l’architecture de A à Z. En fait, je pense même que le problème source de ce genre d’outils est précisément là : ils sont conçus pour ce cas de build simple où tu rentres très exactement dans les cases prévues, mais pas pour la vie réelle où tu as des cas plus complexes sur lesquels tu n’as pas la main.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Bof
Posté par barmic 🦦 . Évalué à 2.
Ça demande une certaine mauvaise fois ou à minima un haut niveau d’exagération d'affirmer ça quand on voit un maven qui a était conçu pour normaliser à fond les builds et qui a rencontré un gros succès. Cette même normalisation d'ailleurs sur la quelle s'appuient gradle/sbt/ant+ivy pour ne pas avoir à réinventer la roue.
Je ne dis pas que l'inverse n'existe pas, mais affirmer que « dans la vie réelle » les conventions ça marche pas et tu dois tweaker c'est y aller fort.
Après c'est toujours pareil, les softs qui continuent de tourner en Java5, de compiler qu'avec gcc 2.92, d'utiliser une interface XUL,… personne n'a envi de payer leur dette à leur place. Ça peut être vu comme une forme de jeunisme, mais c'est aussi une question de ne pas ossifier les technologies.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bof
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Tu déformes mon propos et tu réponds à la déformation, on ne va pas aller loin comme ça.
Le problème des « cases » n'est pas « les vieilles technologies ». D'ailleurs le pire
pom.xmlque j'ai croisé (près de 10 000 – dix mille – lignes était un projet qui avait quatre ans, en Java 11, et qui respectait la structure habituelle des projets Maven.Non, quand je parle de « cases » qui sont trop petites et qui nécessitent des contournements, il ne faut pas aller chercher loin. Par exemple, avoir trois dépôts Docker séparés pour les builds snapshot / release / nightly.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Bof
Posté par barmic 🦦 . Évalué à 1.
Ce n'était pas ma volonté, mais quand j'entends « projet sur le quel on a pas la main » c'est généralement pour expliquer que la dette technique elle est chère etc.
Je ne vois pas comment c'est expliquable (autrement que par de l'incompétence1). Donne leur le build tool que tu veux ils feront n'importe quoi avec. D'ailleurs être en mesure de sortir ça avec maven, ça me fait peur d'imaginer ce que ça pourrait donner avec gradle.
On gère ça avec une properties
dockerRepositoryqu'on set comme on le souhaite. On a pas de nightly, mais dev par défaut, qlf on surcharge via la CLI et release c'est reset dans un completion goal du release prepare. Ça convient peut être pas chez vous.je veux pas être particulièrement insultant le projet fait peut être des choses très bien au demeurant. C'est juste que je ne vois pas comment ça peut arriver autrement que sans comprendre maven ou en essayant de lui tordre le bras vraiment fort. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bof
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 26 septembre 2022 à 14:59.
Je ne parle pas de projet sur lesquels on a pas la main mais de cas sur lesquels on a pas la main. C’est plus général que le simple projet, ça implique des règles internes à l’entreprise, etc.
C’était un exemple pour te montrer que « n’importe quoi » n’implique pas « vieux projet » ou « technologies pourries », et réciproquement. Et oui, ce truc est débile et impossible à maintenir en l’état.
Là encore, fais des suppositions, puis tu tires des conclusions à partir des suppositions que tu as tirées – qui sont donc fausses. D’une part le problème n’est pas l’URL du dépôt mais l’identification ; d’autre part ça concerne Jenkins et pas Docker, donc « une properties » n’est pas une solution utilisable (en tous cas pas de façon simple sans dupliquer une tâche).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Bof
Posté par barmic 🦦 . Évalué à 2.
J'ai décris comment moi j'ai fais et fini en disant que ça ne suffit peut être pas pour tout le monde. On arrivait à le faire aussi avec jenkins via les secrets.
Je ne dis pas que tu ne rencontre pas de problème, mais que dire que dès que tu es multi-dépôts ça ne marche pas c'est faux. Ils ne gèrent probablement pas tous les cas (j'imagine par exemple que selon le runtime que tu utilise ça va coincer), ça pourrait être plus simple, ça pourrait être mieux géré (jenkins en soit est relou à ustiliser).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bof
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 1.
Encore une fois, tu inventes un élément et tu réponds à cet élément. Mon propos, c’est qu’on doit bidouiller, pas que « ça ne marche pas ».
Ici, j’ai dû bidouiller parce que mon besoin ne rentrait pas dans les cases prévues : le plugin ne peut s’authentifier qu’à un seul dépôt (et crée un fichier de configuration dédié, donc enchâsser les configurations l’une dans l’autre ne fonctionne pas). Il y bien un plugin qui le permet, mais c’est pas celui qui est installé sur le serveur Jenkins et qu’on utilise pour tout le reste. Et c’est pas un plugin exotique, hein, c’est les standards.
Mais en fait on s’en fout, c’est qu’un exemple. Je ne viens pas ici pour demander comment faire ce truc en particulier.
Alors oui, dans un monde parfait, théorique et tout, je me serais contenté d’utiliser le plugin qui va bien dans Jenkins et tout aurait été parfait, doux et rose. Mais justement, on est pas dans un monde théorique et je dois composer avec des contraintes extérieures. Et c’est précisément là que le bât blesse : trop souvent ces outils de configuration par DSL partent du principe que tu es en Théorie, ne sont pas conçus pour gérer autre chose, et dès que tu t’en éloignes c’est l’enfer.
Et ça n’est pas la peine de venir expliquer qu’il suffit de changer d’outil ou de rentrer dans une configuration « standard » : le problème est précisément quand on ne peut pas faire ce genre de chose, quelle qu’en soit la raison.
La connaissance libre : https://zestedesavoir.com
# Configuration ?
Posté par Pol' uX (site web personnel) . Évalué à 1.
Les vrais projets logiciels se concentre sur les vrais besoins ; la configuration c'est futile et ça embrouille les usagers.
Adhérer à l'April, ça vous tente ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.