The Go team has been making progress toward a complete fix to this problem.
Go 1.19 added "go mod download -reuse", which lets it be told about the previous download result including the Git commit refs involved and their hashes. If the relevant parts of the server's advertised ref list is unchanged since the previous download, then the refresh will do nothing more than the ref list, which is very cheap.
The proxy.golang.org service has not yet been updated to use -reuse, but it is on our list of planned work for this year.
On the one hand Sourcehut claims this is a big problem for them, but on the other hand Sourcehut also has told us they don't want us to put in a special case to disable background refreshes (see the comment thread elsewhere on this page [1]).
The offer to disable background refreshes until a more complete fix can be deployed still stands, both to Sourcehut and to anyone else who is bothered by the current load. Feel free to post an issue at https://go.dev/issue/new or email me at rsc@golang.org if you would like to opt your server out of background refreshes.
[1] https://news.ycombinator.com/item?id=34311621
La réponse est plus ou moins satisfaisante. D'un point de vue du développeur, c'est vraiment un plus que de profiter du cache de Google ?
Dans l'écosystème Javascript (qui n'est pas un exemple), on peut se passer du registre NPM, et en utiliser un autre. Ou bien spécifier des dépendances git directes, qui sont récupérées sans miroir caché.
J'ai l'impression que c'est un défaut de conception des outils de gestion de dépendances en Go.
La réponse est plus ou moins satisfaisante. D'un point de vue du développeur, c'est vraiment un plus que de profiter du cache de Google ?
Pour pratiquer grandement le miroir de Go, oui c'est un réel plus car beaucoup plus rapide (qq ms contrairement à plusieurs secondes voire plus).
Avec le miroir, on télécharge uniquement la version ou tag demandé qui est en plus compressé. Sans le miroir, on fait un git clone (donc plusieurs Mo).
De plus, avec le miroir il y a un contrôle du checksum (permettant de ne pas avoir des attaques sur les dépendances), il n'est donc pas possible de supprimer un tag et d'en poser un nouveau sans alerte lors de la compilation.
Posté par Glandos .
Évalué à 3.
Dernière modification le 10 janvier 2023 à 15:10.
Sans le miroir, on fait un git clone (donc plusieurs Mo).
Il existe les sparse checkouts. Plutôt léger.
De plus, avec le miroir il y a un contrôle du checksum
C'est pour ça que Ruby/JS ont des lockfiles. J'étais pas très chaud au début, mais c'est quand même pas mal : un résumé des dépendances calculé une fois.
car beaucoup plus rapide
Yarn utilise un cache local sur ma machine, ça va plutôt vite, vu que la plupart des projets utilisent souvent des dépendances identiques. Et si je veux mutualiser, je monte un registre intermédiaire type Verdaccio. Visiblement, athens fait ça, comme discuté en dessous. Et ça a pas l'air trop dur à mettre en place (si on accepte docker) : https://docs.gomods.io/
Posté par woffer 🐧 .
Évalué à 3.
Dernière modification le 10 janvier 2023 à 15:43.
Yarn utilise un cache local sur ma machine, ça va plutôt vite, vu que la plupart des projets utilisent souvent des dépendances identiques.
Go dispose aussi d'un cache local. Par exemple sur ma machine de dev par exemple, je ne vais pratiquement jamais chercher sur le miroir sauf lorsque que je vérifie s'il y a des maj alors dans ce cas, je l'utilise (et c'est très rapide)
L'avantage d'un cache optimisé est que cela va vite aussi dans les CI qui fonctionnent souvent dans du docker et sans cache car les builds sont lancés dans des containers vierges (sauf si vous mettez un cache S3 par exemple).
Dans l'écosystème Javascript (qui n'est pas un exemple), on peut se passer du registre NPM, et en utiliser un autre. Ou bien spécifier des dépendances git directes, qui sont récupérées sans miroir caché.
Tu peux aussi le faire en Go mais ce n'est pas le comportement par défaut. Mais tu perds le benefice du miroir par contre tu es anonyme (ce qui n'est pas le cas avec le miroir par défaut car il (et Google aussi) voit passer toutes les requêtes)
Pour info, il est possible de mettre en place un miroir perso ou au niveau de son entreprise (ex: https://github.com/gomods/athens) pour éviter de passer par celui de Go (hébergé par Google).
# Une réponse de rsc (le mainteneur en chef du Go)
Posté par woffer 🐧 . Évalué à 5. Dernière modification le 10 janvier 2023 à 08:20.
https://news.ycombinator.com/item?id=34310674
[^] # Re: Une réponse de rsc (le mainteneur en chef du Go)
Posté par Glandos . Évalué à 4.
La réponse est plus ou moins satisfaisante. D'un point de vue du développeur, c'est vraiment un plus que de profiter du cache de Google ?
Dans l'écosystème Javascript (qui n'est pas un exemple), on peut se passer du registre NPM, et en utiliser un autre. Ou bien spécifier des dépendances git directes, qui sont récupérées sans miroir caché.
J'ai l'impression que c'est un défaut de conception des outils de gestion de dépendances en Go.
[^] # Re: Une réponse de rsc (le mainteneur en chef du Go)
Posté par Misc (site web personnel) . Évalué à 3.
Non, mais du point de vue de github ou d'autres forges, sans doute.
Est ce que Sourcehut consomme plus de bande passante avec le cache de Google que si il n'était pas la ?
[^] # Re: Une réponse de rsc (le mainteneur en chef du Go)
Posté par woffer 🐧 . Évalué à 3.
Pour pratiquer grandement le miroir de Go, oui c'est un réel plus car beaucoup plus rapide (qq ms contrairement à plusieurs secondes voire plus).
Avec le miroir, on télécharge uniquement la version ou tag demandé qui est en plus compressé. Sans le miroir, on fait un git clone (donc plusieurs Mo).
De plus, avec le miroir il y a un contrôle du checksum (permettant de ne pas avoir des attaques sur les dépendances), il n'est donc pas possible de supprimer un tag et d'en poser un nouveau sans alerte lors de la compilation.
[^] # Re: Une réponse de rsc (le mainteneur en chef du Go)
Posté par Glandos . Évalué à 3. Dernière modification le 10 janvier 2023 à 15:10.
Il existe les sparse checkouts. Plutôt léger.
C'est pour ça que Ruby/JS ont des lockfiles. J'étais pas très chaud au début, mais c'est quand même pas mal : un résumé des dépendances calculé une fois.
Yarn utilise un cache local sur ma machine, ça va plutôt vite, vu que la plupart des projets utilisent souvent des dépendances identiques. Et si je veux mutualiser, je monte un registre intermédiaire type Verdaccio. Visiblement, athens fait ça, comme discuté en dessous. Et ça a pas l'air trop dur à mettre en place (si on accepte docker) : https://docs.gomods.io/
[^] # Re: Une réponse de rsc (le mainteneur en chef du Go)
Posté par woffer 🐧 . Évalué à 3. Dernière modification le 10 janvier 2023 à 15:43.
Go dispose aussi d'un cache local. Par exemple sur ma machine de dev par exemple, je ne vais pratiquement jamais chercher sur le miroir sauf lorsque que je vérifie s'il y a des maj alors dans ce cas, je l'utilise (et c'est très rapide)
L'avantage d'un cache optimisé est que cela va vite aussi dans les CI qui fonctionnent souvent dans du docker et sans cache car les builds sont lancés dans des containers vierges (sauf si vous mettez un cache S3 par exemple).
[^] # Re: Une réponse de rsc (le mainteneur en chef du Go)
Posté par woffer 🐧 . Évalué à 2.
Tu peux aussi le faire en Go mais ce n'est pas le comportement par défaut. Mais tu perds le benefice du miroir par contre tu es anonyme (ce qui n'est pas le cas avec le miroir par défaut car il (et Google aussi) voit passer toutes les requêtes)
Pour info, il est possible de mettre en place un miroir perso ou au niveau de son entreprise (ex: https://github.com/gomods/athens) pour éviter de passer par celui de Go (hébergé par Google).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.