• # Une r√©ponse de rsc (le mainteneur en chef du Go)

    Post√©¬†par¬† . √Čvalu√©¬†√†¬†5. Derni√®re modification le 10/01/23 √† 08:20.

    https://news.ycombinator.com/item?id=34310674

    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

    • [^] # Re: Une r√©ponse de rsc (le mainteneur en chef du Go)

      Post√©¬†par¬† . √Č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¬† (site web personnel) . √Čvalu√©¬†√†¬†3.

        D'un point de vue du développeur, c'est vraiment un plus que de
        profiter du cache de Google ?

        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¬† . √Čvalu√©¬†√†¬†3.

        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.

        • [^] # Re: Une r√©ponse de rsc (le mainteneur en chef du Go)

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†3. Derni√®re modification le 10/01/23 √† 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/

          • [^] # Re: Une r√©ponse de rsc (le mainteneur en chef du Go)

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†3. Derni√®re modification le 10/01/23 √† 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).

      • [^] # Re: Une r√©ponse de rsc (le mainteneur en chef du Go)

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

        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).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.