LCC 297 - Lockless design
23 views
Skip to first unread message
Emmanuel Bernard
Jun 12, 2023, 9:00:54 AM6/12/23
to lescast...@googlegroups.com
Guillaume, Arnaud et Emmanuel discutent des nouvelles de mai et juin. La communauté Rust, WebAssembly. Guava, Debezium, Kafka, de flame graph, d’open source et bien sûr les large language models. On répond aussi à la question fondamentale: mais pourquoi Maven n’a pas de fichier .lock ?
Emmanuel
Cédric Champeau
Jun 12, 2023, 9:47:08 AM6/12/23
to lescast...@googlegroups.com
Alors petite bêtise dite sur Gradle : il y a bien des fichiers de lock. Il est fortement recommandé de les utiliser si vous avez des range : https://docs.gradle.org/current/userguide/dependency_locking.html
Il y a vraiment plein de choses dans Gradle, c'est fou ;)
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAEW2RjLbBMJpXJKq2Mu7O1Svchs1aubiJ5YiFFjF7VJ%3D2BVGSA%40mail.gmail.com.
Remi Forax
Jun 12, 2023, 10:27:31 AM6/12/23
to lescastcodeurs
From: "Cédric Champeau" <cedric....@gmail.com>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Monday, June 12, 2023 3:46:54 PM
Subject: Re: [LCC] LCC 297 - Lockless design
Alors petite bêtise dite sur Gradle : il y a bien des fichiers de lock. Il est fortement recommandé de les utiliser si vous avez des range : https://docs.gradle.org/current/userguide/dependency_locking.htmlIl y a vraiment plein de choses dans Gradle, c'est fou ;)
En même temps, il est fortement conseillé de jamais utiliser de 'range' si tu veux pas te prendre une clé à molette dans la tronche par un collègue qui vient de passer une semaine à essayer de compendre pourquoi la resolution des dependencies marche bizarrement.
Pour moi, on néglige trop souvent les approches low tech type monkey wrenching pour répondre aux problèmes actuelles des entreprises digitales.
Rémi
--Le lun. 12 juin 2023 à 15:00, Emmanuel Bernard <emma...@lescastcodeurs.com> a écrit :--Guillaume, Arnaud et Emmanuel discutent des nouvelles de mai et juin. La communauté Rust, WebAssembly. Guava, Debezium, Kafka, de flame graph, d’open source et bien sûr les large language models. On répond aussi à la question fondamentale: mais pourquoi Maven n’a pas de fichier .lock ?Emmanuel
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAEW2RjLbBMJpXJKq2Mu7O1Svchs1aubiJ5YiFFjF7VJ%3D2BVGSA%40mail.gmail.com.
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CADQzvmnQdVumfP%3DTLmD%3DoOTjc6z%3D9hAC1tgT_WkxKah8Fq4QRQ%40mail.gmail.com.
Cédric Champeau
Jun 12, 2023, 10:38:14 AM6/12/23
to lescast...@googlegroups.com
On recommande pas en Java parce qu'on n'a pas la culture. MAIS, si tu considères que semantic versioning, c'est quelque chose qui a de la valeur, alors il est tout à fait légitime d'utiliser les ranges et le locking. C'est aussi pour ça que Gradle supporte des "modèles de version" plus avancés, par exemple, tu peux dire "donne moi quelque chose dans le range [1.0, 2.0[, et dans cette range, je préfère la version 1.1" ([1]). Parce qu'a priori, passer à 1.2 ne devrait pas péter votre code. Donc on a des utilisateurs qui font ça à grande échelle (je pense à Netflix, du temps où je bossais pour Gradle), parce qu'ils utilisent du semantic versioning partout.
[1] pour les curieux, ça s'exprime par un require "[1.0, 2.0[" prefer "1.1" en Gradle, voir https://docs.gradle.org/current/userguide/rich_versions.html
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/30374268.78803978.1686580045659.JavaMail.zimbra%40univ-eiffel.fr.
Réda Housni Alaoui
Jun 12, 2023, 10:44:11 AM6/12/23
to lescastcodeurs
Sur Maven, alors que j'évite les version range, j'utilise toujours https://maven.apache.org/enforcer/enforcer-rules/requireUpperBoundDeps.html .
C'est une sorte de lockfile in fine, mais construit à la main.
Cela permet de verrouiller les dépendances transitives et d'éviter des surprises au runtime.
C'est une sorte de lockfile in fine, mais construit à la main.
Cela permet de verrouiller les dépendances transitives et d'éviter des surprises au runtime.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CADQzvmmNEajYT4DiXc46h333kmtpbqw8g-e%2B2ZweeBESEfo6tA%40mail.gmail.com.
Baptiste Mathus
Jun 13, 2023, 4:47:22 AM6/13/23
to lescast...@googlegroups.com
+1 Rémi.
Pour moi, les ranges sont une feature du passé. Je pense que de nos jours, on devrait carrément préférer une version fixe accompagnée d'une automatisation à la Dependabot/Renovate pour garder ta stack à jour.
Utiliser des ranges va te péter ton build à un moment inopportun, et surtout sans changement de ton côté. GitOps FTW, tout changement dans ta stack devrait venir d'une PR/commit de *ton* côté.
Less is more.
-- Baptiste
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/30374268.78803978.1686580045659.JavaMail.zimbra%40univ-eiffel.fr.
Cédric Champeau
Jun 13, 2023, 4:59:36 AM6/13/23
to lescast...@googlegroups.com
Le mar. 13 juin 2023 à 10:47, Baptiste Mathus <m...@batmat.net> a écrit :
+1 Rémi.Pour moi, les ranges sont une feature du passé. Je pense que de nos jours, on devrait carrément préférer une version fixe accompagnée d'une automatisation à la Dependabot/Renovate pour garder ta stack à jour.
C'est une façon "simple" de faire, mais certainement pas la plus efficace, loin de là. Parce que renovate ou dependabot n'en ont rien à cirer de la sémantique, des breaking changes, ou simplement ne peuvent pas comprendre tous les schémas de versions qui existent (et merci particulier aux devs qui choisissent des schémas exotiques genre Jetbrains et ses 1.8.11.3.5a). L'autre point c'est que ton dependabot ou renovate ne fonctionne pas avec les dépendances transitives, uniquement avec tes dépendances directes.
Les ranges sont une meilleure idée à condition, et c'est vraiment là le point important, à condition de définir à la fois une version préférée dans le range ET d'utiliser le locking. Le range permet de définir le spectre des versions acceptables, le prefer permet de dire "ça, c'est la version avec laquelle j'ai testé et ça marche", et le locking permet de vérouiller pour la reproductibilité. C'est le meilleur des 2 mondes.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CANWgJS6yXKQVF6THhFf1Ap9YpWBSW-aWFmpV61LR_KUJvr2xmw%40mail.gmail.com.
Jérémie Bresson
Jun 13, 2023, 7:58:25 AM6/13/23
to lescastcodeurs
+1 pour la vision de Cédric: "à condition de définir à la fois une version préférée dans le range ET d'utiliser le locking"
Et même si Arnaud l'a un peu dit en disant "c'est culturel chez Java de ne pas utiliser les ranges".
Pour moi, si c'est pas plus utilisé en Java c'est à cause de la faiblesses de l'outil mainstream (Maven).
Comme par défaut (comprendre sans plugins ou autres artifices), il n'y a pas les deux pré-requis dans Maven, c'est devenu une "best-practice" pour avoir toujours la même resolution (qui est l'objectif premier pour éviter les surprises, comme tout le monde s'accorde à le dire).
Résultat: les ranges ne sont pas utilisés et et tout le monde est parti sur des solutions plus simple (ou low-tech comme dit Rémi) histoire de ne pas avoir de problème.
Mais dans cette histoire de poule et d'oeuf, il ne faut pas inverser les roles.
Les ranges de version sont un peu plus courant dans le microcosme OSGi (qui a défini de nombreux concepts bien avant Maven), mais c'est parce que les outils aident dans ce sens et que le semantic-versioning y est plus adopté.
Jérémie
Emmanuel Lécharny
Jun 14, 2023, 3:01:06 AM6/14/23
to lescast...@googlegroups.com
Ca me fait un peu rigoler quand je pense à ceux qui utilisent des ranges
et qui se dont pêter la gueule par une dépendance qui est dans le range
*mais* qui introduit une API pêtée ou qui change de comportement parce
que mal codée.
Je m'explique: étant un des dev de Apache LDAP API, on a eu des tas de
problèmes avec des changements anodins - en tout cas qui semblaient
anodins - mais qui pêtaient les apps au dessus. Typiquement, parce qu'on
avait mal codé un hashcode/equals, et que JNDI - qu'on utilise en
sous-jacent pour certaines features, comme de la conversion JNDI <->
LDAP API - utilise des HashMaps dont l'implem changeait entre deux
version de Java.
Oui, je sais, c'est notre faute, et on n'avait qu'à faire plus attention
aux hashcode/equals, mais shit happens. Et du coup, ceux qui utilisaient
notre lib dans la toute dernière version pouvait très bien l'avoir dans
l'OS.
Autre cas d'espèce, dans Apache MINA, où on a introduit par mégarde un
changement dans l'API dans une version corrective. Du coup tu utilisais
la 2.0.23 et ça marchait plus comme pour la 2.0.22 (ce ne sont pas les
bonnes version, juste que je ne me rappelle pas de quand l'erreur a été
commise). Evidemment ça a pêté à la gueule de ceux qui ont utilisés
cette mauvaise version... On a dû re-releaser dans l'urgence.
Mon opinion, c'est qu'un package/app est testé *et* validée pour *UNE*
version de chacune des libs dont il dépend. Utiliser des ranges, c'est
vraiement vouloir prendre des risques.
Quyand à dépendabête, c'est pas ce truc à la con qui pollue mes mailing
lists en m'expliquant doctement qu'une version de dépendance a été
upgradée, alors qu'un "mvn versions:display-dependency-updates" fait le
boulot *QUAND JE VEUX* ?
Bon, bref, j'aime bien la version fixée et j'aime pas dépendachose...
On 13/06/2023 10:59, Cédric Champeau wrote:
>
>
> Le mar. 13 juin 2023 à 10:47, Baptiste Mathus <m...@batmat.net
> <mailto:m...@batmat.net>> a écrit :
> <mailto:fo...@univ-mlv.fr>> a écrit :
>
>
>
> ------------------------------------------------------------------------
>
> *From: *"Cédric Champeau" <cedric....@gmail.com
> <mailto:cedric....@gmail.com>>
> *To: *"lescastcodeurs" <lescast...@googlegroups.com
> <mailto:lescast...@googlegroups.com>>
> *Sent: *Monday, June 12, 2023 3:46:54 PM
> *Subject: *Re: [LCC] LCC 297 - Lockless design
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel...@busit.com https://www.busit.com/
et qui se dont pêter la gueule par une dépendance qui est dans le range
*mais* qui introduit une API pêtée ou qui change de comportement parce
que mal codée.
Je m'explique: étant un des dev de Apache LDAP API, on a eu des tas de
problèmes avec des changements anodins - en tout cas qui semblaient
anodins - mais qui pêtaient les apps au dessus. Typiquement, parce qu'on
avait mal codé un hashcode/equals, et que JNDI - qu'on utilise en
sous-jacent pour certaines features, comme de la conversion JNDI <->
LDAP API - utilise des HashMaps dont l'implem changeait entre deux
version de Java.
Oui, je sais, c'est notre faute, et on n'avait qu'à faire plus attention
aux hashcode/equals, mais shit happens. Et du coup, ceux qui utilisaient
notre lib dans la toute dernière version pouvait très bien l'avoir dans
l'OS.
Autre cas d'espèce, dans Apache MINA, où on a introduit par mégarde un
changement dans l'API dans une version corrective. Du coup tu utilisais
la 2.0.23 et ça marchait plus comme pour la 2.0.22 (ce ne sont pas les
bonnes version, juste que je ne me rappelle pas de quand l'erreur a été
commise). Evidemment ça a pêté à la gueule de ceux qui ont utilisés
cette mauvaise version... On a dû re-releaser dans l'urgence.
Mon opinion, c'est qu'un package/app est testé *et* validée pour *UNE*
version de chacune des libs dont il dépend. Utiliser des ranges, c'est
vraiement vouloir prendre des risques.
Quyand à dépendabête, c'est pas ce truc à la con qui pollue mes mailing
lists en m'expliquant doctement qu'une version de dépendance a été
upgradée, alors qu'un "mvn versions:display-dependency-updates" fait le
boulot *QUAND JE VEUX* ?
Bon, bref, j'aime bien la version fixée et j'aime pas dépendachose...
On 13/06/2023 10:59, Cédric Champeau wrote:
>
>
> Le mar. 13 juin 2023 à 10:47, Baptiste Mathus <m...@batmat.net
>
>
>
> ------------------------------------------------------------------------
>
> *From: *"Cédric Champeau" <cedric....@gmail.com
> <mailto:cedric....@gmail.com>>
> *To: *"lescastcodeurs" <lescast...@googlegroups.com
> <mailto:lescast...@googlegroups.com>>
> *Sent: *Monday, June 12, 2023 3:46:54 PM
> *Subject: *Re: [LCC] LCC 297 - Lockless design
>
> Alors petite bêtise dite sur Gradle : il y a bien des
> fichiers de lock. Il est fortement recommandé de les
> utiliser si vous avez des range :
> https://docs.gradle.org/current/userguide/dependency_locking.html <https://docs.gradle.org/current/userguide/dependency_locking.html>
> Alors petite bêtise dite sur Gradle : il y a bien des
> fichiers de lock. Il est fortement recommandé de les
> utiliser si vous avez des range :
>
> Il y a vraiment plein de choses dans Gradle, c'est fou ;)
>
>
> En même temps, il est fortement conseillé de jamais utiliser de
> 'range' si tu veux pas te prendre une clé à molette dans la
> tronche par un collègue qui vient de passer une semaine à
> essayer de compendre pourquoi la resolution des dependencies
> marche bizarrement.
>
> Pour moi, on néglige trop souvent les approches low tech type
> monkey wrenching pour répondre aux problèmes actuelles des
> entreprises digitales.
>
> Rémi
>
>
>
> Le lun. 12 juin 2023 à 15:00, Emmanuel Bernard
> <emma...@lescastcodeurs.com
> <mailto:emma...@lescastcodeurs.com>> a écrit :
> Il y a vraiment plein de choses dans Gradle, c'est fou ;)
>
>
> En même temps, il est fortement conseillé de jamais utiliser de
> 'range' si tu veux pas te prendre une clé à molette dans la
> tronche par un collègue qui vient de passer une semaine à
> essayer de compendre pourquoi la resolution des dependencies
> marche bizarrement.
>
> Pour moi, on néglige trop souvent les approches low tech type
> monkey wrenching pour répondre aux problèmes actuelles des
> entreprises digitales.
>
> Rémi
>
>
>
> Le lun. 12 juin 2023 à 15:00, Emmanuel Bernard
> <emma...@lescastcodeurs.com
>
> Guillaume, Arnaud et Emmanuel discutent des nouvelles de
> mai et juin. La communauté Rust, WebAssembly. Guava,
> Debezium, Kafka, de flame graph, d’open source et bien
> sûr les large language models. On répond aussi à la
> question fondamentale: mais pourquoi Maven n’a pas de
> fichier .lock ?
>
> https://lescastcodeurs.com/2023/06/12/lcc-297-lockless-design/ <https://lescastcodeurs.com/2023/06/12/lcc-297-lockless-design/>
> Guillaume, Arnaud et Emmanuel discutent des nouvelles de
> mai et juin. La communauté Rust, WebAssembly. Guava,
> Debezium, Kafka, de flame graph, d’open source et bien
> sûr les large language models. On répond aussi à la
> question fondamentale: mais pourquoi Maven n’a pas de
> fichier .lock ?
>
>
> Emmanuel
> --
> Vous recevez ce message, car vous êtes abonné au groupe
> Google Groupes "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir
> d'e-mails le concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com
> <mailto:lescastcodeur...@googlegroups.com>.
> Emmanuel
> --
> Vous recevez ce message, car vous êtes abonné au groupe
> Google Groupes "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir
> d'e-mails le concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com
> Cette discussion peut être lue sur le Web à l'adresse
> https://groups.google.com/d/msgid/lescastcodeurs/CAEW2RjLbBMJpXJKq2Mu7O1Svchs1aubiJ5YiFFjF7VJ%3D2BVGSA%40mail.gmail.com <https://groups.google.com/d/msgid/lescastcodeurs/CAEW2RjLbBMJpXJKq2Mu7O1Svchs1aubiJ5YiFFjF7VJ%3D2BVGSA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe
> Google Groupes "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir
> d'e-mails le concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com
> <mailto:lescastcodeur...@googlegroups.com>.
> --
> Vous recevez ce message, car vous êtes abonné au groupe
> Google Groupes "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir
> d'e-mails le concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com
> Cette discussion peut être lue sur le Web à l'adresse
> https://groups.google.com/d/msgid/lescastcodeurs/CADQzvmnQdVumfP%3DTLmD%3DoOTjc6z%3D9hAC1tgT_WkxKah8Fq4QRQ%40mail.gmail.com <https://groups.google.com/d/msgid/lescastcodeurs/CADQzvmnQdVumfP%3DTLmD%3DoOTjc6z%3D9hAC1tgT_WkxKah8Fq4QRQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe
> Google Groupes "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails
> le concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com
> <mailto:lescastcodeur...@googlegroups.com>.
> --
> Vous recevez ce message, car vous êtes abonné au groupe
> Google Groupes "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails
> le concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com
> Cette discussion peut être lue sur le Web à l'adresse
> https://groups.google.com/d/msgid/lescastcodeurs/30374268.78803978.1686580045659.JavaMail.zimbra%40univ-eiffel.fr <https://groups.google.com/d/msgid/lescastcodeurs/30374268.78803978.1686580045659.JavaMail.zimbra%40univ-eiffel.fr?utm_medium=email&utm_source=footer>.
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe
> Google Groupes "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com
> <mailto:lescastcodeur...@googlegroups.com>.
> --
> Vous recevez ce message, car vous êtes abonné au groupe
> Google Groupes "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com
> Cette discussion peut être lue sur le Web à l'adresse
> https://groups.google.com/d/msgid/lescastcodeurs/CANWgJS6yXKQVF6THhFf1Ap9YpWBSW-aWFmpV61LR_KUJvr2xmw%40mail.gmail.com <https://groups.google.com/d/msgid/lescastcodeurs/CANWgJS6yXKQVF6THhFf1Ap9YpWBSW-aWFmpV61LR_KUJvr2xmw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com
> <mailto:lescastcodeur...@googlegroups.com>.
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> "lescastcodeurs".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com
> Cette discussion peut être lue sur le Web à l'adresse
> https://groups.google.com/d/msgid/lescastcodeurs/CADQzvmkTVBOztdBKGDn6MNUgqkrTq3g5JHNS2qMkiAs8WDWWtw%40mail.gmail.com <https://groups.google.com/d/msgid/lescastcodeurs/CADQzvmkTVBOztdBKGDn6MNUgqkrTq3g5JHNS2qMkiAs8WDWWtw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel...@busit.com https://www.busit.com/
Cédric Champeau
Jun 14, 2023, 3:16:16 AM6/14/23
to lescast...@googlegroups.com
C'est assez naïf comme point de vue, si tu m'excuses :) Tout d'abord, parce que c'est une erreur commune de penser que ce que tu déclares dans ton fichier de build, c'est ce qui va arriver sur le classpath. C'est tellement commun comme erreur que tout le monde se met à coller des excludes pour contrer le fait que JUSTEMENT, ça n'est pas le cas. Ensuite, ça ne fonctionne *que* pour les dépendances directes, si tant est que ça fonctionne. Par le jeu des dépendances transitives, des "force" et autres <dependencyManagement> blocks, tu as des résultats bien différerents. Ca n'est pas parce que toi, auteur de librairie, tu déclares qu'il te faut "malib" en version 1.1, que c'est ce qui va être résolu au final. Il y a beaucoup de choses à dire sur le sujet. Par exemple, si tu as 2 dépendances:
A -> C:1.1
B -> C:1.2
Alors, Maven va résoudre avec le "nearest first" et te sortir C:1.1. Inverse l'ordre des déclarations de A et B dans ton build, et tu te retrouves avec C:1.2, ce qui est, à mon humble avis, la pire des façons de résoudre un conflit de version, parce qu'autant tu peux gérer à un niveau 1, autant pour des dépendances de niveau plus bas ça devient impossible. C'est pour ça que Maven a pondu `<dependencyManagement>`, qui te dit "à mais oui mais si tu vois C, ALORS utilise 1.1" pour bypasser. Ok, sauf que dependency management n'est pas pris en compte transitivement, donc si tu as un consommateur de ta lib, alors lui ne résoudra pas 1.1 mais 1.2... Dans Gradle TOUTES les versions du graphe sont prises en compte, et il y a une stratégie de résolution "optimiste" qui est "highest wins". Si t'es pas content du résultat, alors tu peux utliser ce qu'on appelle des "Dependency constraints", qui ressemblent au dependency management, mais qui elles sont prises en compte transitivement. L'objectif d'un moteur de résolution de dépendances est donc de trouver la "meilleure" solution, étant donné un certain nombres de contraintes. Utiliser des "rich versions", c'est exprimer ces contraintes de façons beaucoup plus claires.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/d3e391ef-eb62-88f7-5954-a6bba3e5e644%40gmail.com.
Alain Hélaïli
Jun 14, 2023, 3:29:51 AM6/14/23
to lescast...@googlegroups.com
Désolé que le truc à la con pollue tes emails. Note que tu peux retirer les notifications de sécurité dans tes réglages d’abonnement à un repo et qu’il est relativement simple de filtrer ces emails vu que le nom de l’expéditeur est "dependabot[bot]"
Après, Dependabot, c’est avant tout le truc qui te prévient qu’une de tes dépendances comporte une vulnérabilité: Dependabot security updates
Tu peux également le configurer pour te prévenir des mises à jour, mais ce n’est pas obligatoire. Tu peux configurer la fréquence de cette verification et tu restes celui qui merge les PRs, donc tu restes en contrôle: Dependabot version updates
Enfin, il existe maintenant une API et des GitHub Actions par dessus cette API qui permettent d’informer Dependabot des dépendances effectivement utilisées lors du build (Maven ou Gradle) : Dependency submission API
Alain Hélaïli
GitHub
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/d3e391ef-eb62-88f7-5954-a6bba3e5e644%40gmail.com.
Emmanuel Lécharny
Jun 14, 2023, 3:40:49 AM6/14/23
to lescast...@googlegroups.com
Oui, enfin, je caricature ;-)
En l'occurrence, c'est ce qu'on appelle 'a self inflicted wound' !
En fait, ce que je n'aime pas, c'est d'en recevoir 10 par jour, ce qui
est le cas sur les projets sur lesquels je bosse, parce que toutes les
PRs de 10 projets arrivent dans ma boîte au lettres, et que sur ces
projets, on doit avoir pas loin de 100 dépendances...
Mais je te l'accorde, dependabot en soit est utile. C'est juste que je
n'ai pas mis de triggers pour déplacer les PR dans un répertoire à part,
que je suis floaded par ces PRs et que du coup je ne les regarde même plus!
PS/ et non, je n'envisage pas de supprimer ces alertes. Je dois être
maso ;-)
On 14/06/2023 09:29, 'Alain Hélaïli' via lescastcodeurs wrote:
> Désolé que le truc à la con pollue tes emails. Note que tu peux retirer
> les notifications de sécurité dans tes réglages d’abonnement à un repo
> et qu’il est relativement simple de filtrer ces emails vu que le nom de
> l’expéditeur est "dependabot[bot]"
>
> Après, Dependabot, c’est avant tout le truc qui te prévient qu’une de
> tes dépendances comporte une vulnérabilité: Dependabot security updates
> <https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates>
> https://groups.google.com/d/msgid/lescastcodeurs/841c46dc-a81b-46cd-b7ef-7c2713d65fce%40Canary <https://groups.google.com/d/msgid/lescastcodeurs/841c46dc-a81b-46cd-b7ef-7c2713d65fce%40Canary?utm_medium=email&utm_source=footer>.
En l'occurrence, c'est ce qu'on appelle 'a self inflicted wound' !
En fait, ce que je n'aime pas, c'est d'en recevoir 10 par jour, ce qui
est le cas sur les projets sur lesquels je bosse, parce que toutes les
PRs de 10 projets arrivent dans ma boîte au lettres, et que sur ces
projets, on doit avoir pas loin de 100 dépendances...
Mais je te l'accorde, dependabot en soit est utile. C'est juste que je
n'ai pas mis de triggers pour déplacer les PR dans un répertoire à part,
que je suis floaded par ces PRs et que du coup je ne les regarde même plus!
PS/ et non, je n'envisage pas de supprimer ces alertes. Je dois être
maso ;-)
On 14/06/2023 09:29, 'Alain Hélaïli' via lescastcodeurs wrote:
> Désolé que le truc à la con pollue tes emails. Note que tu peux retirer
> les notifications de sécurité dans tes réglages d’abonnement à un repo
> et qu’il est relativement simple de filtrer ces emails vu que le nom de
> l’expéditeur est "dependabot[bot]"
>
> Après, Dependabot, c’est avant tout le truc qui te prévient qu’une de
> tes dépendances comporte une vulnérabilité: Dependabot security updates
>
> Tu peux également le configurer pour te prévenir des mises à jour, mais
> ce n’est pas obligatoire. Tu peux configurer la fréquence de cette
> verification et tu restes celui qui merge les PRs, donc tu restes en
> contrôle: Dependabot version updates
> <https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates>
> Tu peux également le configurer pour te prévenir des mises à jour, mais
> ce n’est pas obligatoire. Tu peux configurer la fréquence de cette
> verification et tu restes celui qui merge les PRs, donc tu restes en
> contrôle: Dependabot version updates
>
> Enfin, il existe maintenant une API et des GitHub Actions par dessus
> cette API qui permettent d’informer Dependabot des dépendances
> effectivement utilisées lors du build (Maven ou Gradle) : Dependency
> submission API
> <https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api>
> Enfin, il existe maintenant une API et des GitHub Actions par dessus
> cette API qui permettent d’informer Dependabot des dépendances
> effectivement utilisées lors du build (Maven ou Gradle) : Dependency
> submission API
>
> Alain Hélaïli
> GitHub
>
> On Wednesday, Jun 14, 2023 at 9:01 AM, Emmanuel Lécharny
> Alain Hélaïli
> GitHub
>
> On Wednesday, Jun 14, 2023 at 9:01 AM, Emmanuel Lécharny
Arnaud Héritier
Jun 14, 2023, 6:48:03 AM6/14/23
to lescast...@googlegroups.com
Finalement on a raison de raconter des conneries de temps à autre, cela anime le groupe de discussion.
Pour en revenir au sujet des range, résolutions etc il faut avouer que l’approche maven est comme souvent simple(iste) car crée il y a très très longtemps et que faute de moyens vs les problèmes de gestion du changement (ou de compatibilité) et bien ça reste pauvre.
Osgi existait déjà quand maven (au moins 2) a vu le jour et les problèmes de versionning associés ont justement demandé à faire des efforts pour que fonctionne tycho.
Avec des si on referai le monde et on ne peut pas nier que Gradle est plus puissant et procure plus de possibilités. Maintenant comme pour toutes les autres fonctionnalités, est-ce si nécessaire et fondamentale…. Ça dépend du contexte.
Aujourd’hui je bosse beaucoup avec du Ruby, du typescript et leur outillage ne m’emballe pas plus que ça…
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/54af1b46-4bc6-4c59-f441-e637454b40d3%40gmail.com.
Arnaud Héritier
Twitter/GitHub/... : aheritier
Emmanuel Lécharny
Jun 14, 2023, 4:10:54 PM6/14/23
to lescast...@googlegroups.com
On 14/06/2023 09:16, Cédric Champeau wrote:
> C'est assez naïf comme point de vue, si tu m'excuses :)
Tout d'abord,
> parce que c'est une erreur commune de penser que ce que tu déclares dans
> ton fichier de build, c'est ce qui va arriver sur le classpath. C'est
> tellement commun comme erreur que tout le monde se met à coller des
> excludes pour contrer le fait que JUSTEMENT, ça n'est pas le cas.
les dépendances directes, mais également les dépendances transitives.
D'un point de vu légal, c'est une obligation: tu n'as par exemple pas le
droit d'embarquer une dépendance dont la license est incompatible avec
celle de ton projet (chez ASF en tout cas). Donc il faut bien contrôler
toutes les dépendances.
Mais effectivement, il est tout à fait possible de se retrouver avec 2
ou plusieurs versions d'un même package par la magie des dépendances
transitives...
alors rende plus permissif les versions utilisables est un pis aller.
Je suis d'accord avec toi, il faudrait que Maven puisse contraindre les
dependances transitives.
Après, il y a toujorus la possibilité de se mettre dans les bras de
OSGi, qui permet de bypasser ces contraintes, auu prix de contorsions
franchement déplaisantes (pour avoir passé *des heures* à corriger des
builds qui ne passaient plus parce qu'il manquait un ';' dans un export,
je trouve que le remède n'est pas loin de tuer le malade...)
Bref, les outils sont imprafaits, mais je trouve que la 'fixation' d'une
version est quelque part la bonne méthode, en espérant qu'un jour Maven
puisse gérer ça intelligemment.
Réda Housni Alaoui
Jun 14, 2023, 4:14:44 PM6/14/23
to lescastcodeurs
> Je suis d'accord avec toi, il faudrait que Maven puisse contraindre les
dependances transitives.
dependances transitives.
Je me répète, mais https://maven.apache.org/enforcer/enforcer-rules/requireUpperBoundDeps.html fait le job :D
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/96587e5b-6a3e-76f3-a5d0-ed13e0f6f760%40gmail.com.
Reply all
Reply to author
Forward
0 new messages