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

    Posté par  . Évalué à 5. DerniĂšre modification le 10 janvier 2023 Ă  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 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/

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

            Posté par  . É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).

      • [^] # 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.