trinity- tout ce que j'utilise est de type semver, je ne suis pas sure si c'est une obligation ou pas mais je n'ai jamais vu quelque chose qui différait jusque là.Mes premières analyses suggèrent en effet que la totalité des packages sur NuGet ont adopté une syntaxe de versions compatible avec semver. Après, la question, c'est de voir si les mainteneurs respectent la sémantique associée
trinity- pour les contraites de versions, oui je pense que ce sont des ranges et après il te met les binding redirect dans ton app.config à l'installation dans le projet (pas toujours d'ailleurs, parfois il faut le mettre à la main pcq ca pète au runtime)Est-ce que tu peux m'expliquer en quelques mots ce que sont les binding redirect ?
trinity- tu peux installer plusieurs versions différentes dans une solution dans des projets différents mais pas au sein d'un même projet. Ca peut être risqué pcq suivant l'ordre de build et les references cross-project que tu peux avoir, tu peux te retrouver avec la mauvaise lib au final dans ton build output.Quand tu parles de l'ordre de build, tu veux dire quoi exactement ?
GuybrushEst-ce que tu peux m'expliquer en quelques mots ce que sont les binding redirect ?Ca te permet de faire beaucoup de
GuybrushQuand tu parles de l'ordre de build, tu veux dire quoi exactement ?C'est bien le cas avec NuGet, c'est juste que je parlais plutôt niveau solution, si tu as plusieurs projets qui dépendent d'assembly de différentes versions, celui qui se retrouvera dans ton build output peut dépendre de l'ordre de build etc. On essaye le plus possible d'avoir des versions uniformes dans chaque projet de nos solutions mais un oubli est vite arrivé dans des solutions énormes...
Le cas classique dans la plupart des package managers, c'est si tu as A qui veut C=1, et B qui veut C=2. Si tu installes A puis B, tu auras C=2, si tu installes B puis A, tu auras C=1. Est-ce le cas avec NuGet, ou est-ce qu'il retient les contraintes de tout ce qui est installé, dans l'optique soit de trouver une solution, soit dans le cas présent d'indiquer qu'il y a un souci ?
GuybrushMerci pour le retour. C'est une vraie jungle ces package managers. Je viens de regarder du coté de Go également, c'est encore pire (parce que tu ne déclares pas forcément tes dépendances, tu peux les importer à la compilation automatiquement en fonction des "import" que tu as fais dans le code, et pire : tu peux directement importer des trucs présents sur des dépôts git, par exemple).Mais dans ce cas-là, comment il sait où aller les chercher lorsqu'il build?
trinityC'est bien le cas avec NuGet, c'est juste que je parlais plutôt niveau solution, si tu as plusieurs projets qui dépendent d'assembly de différentes versions, celui qui se retrouvera dans ton build output peut dépendre de l'ordre de build etc. On essaye le plus possible d'avoir des versions uniformes dans chaque projet de nos solutions mais un oubli est vite arrivé dans des solutions énormes...Ok, donc à priori, une fois que t'as installé un truc, il "oublie" les contraintes liés à ce truc, comme dans Rubygems, PyPi, etc. Il n'y a donc probablement pas un SAT solver pour la résolution des contraintes, mais juste des intersections d'intervalles de versions.
trinityMais dans ce cas-là, comment il sait où aller les chercher lorsqu'il build?C'est dans l'import, par exemple :
import "github.com/AlexandreDecan/Lexpage"
Ce message a été modifié 4 fois.
Dernière modification : 1 mai 2017
à 12:35 par
Guybrush.
1996-2024 — Lexpage v4 — GPLv3 (sources)
page générée le 23 décembre 2024 à 10:31:52