Avoir du code source pour un projet Go en dehors de GOPATH est-il une mauvaise idée?

Je travaille sur un nouveau projet en utilisant Go, et nous sommes tous nouveaux pour Go. Nous suivons la structure standard des répertoires go et avons tout le code sous

$ GOPATH / src / github.com / nom de la société / nom du projet

qui est aussi la racine d'un dépôt git

La disposition standard des chemins recommandée semble un peu étrange, surtout si nous travaillons sur un projet multilingue, par exemple un backend reposant sur http basé sur Go, et un frontal html / javascript. Dans ce cas, je voudrais probablement que ma structure de projet ressemble à ceci:

/
  doc/
  src/
    server/
      main.go
      module1/
        module.go
    client/
      index.html
  Makefile

Mais est-il réellement nécessaire de placer le code dans GOPATH?

En guise d’essai, j’ai créé un petit programme dont le code source se trouvait en dehors de GOPATH. Je pouvais facilement scinder le projet en packages, afin que le mainpackage puisse référencer un foopackage dans un foo/dossier à l'aide de import "./foo".

Autant que je sache, il y a deux choses qui me refusent:

• Un autre code ne peut pas importer ce code. Ce n'est pas un problème car nous construisons un service spécifiquement pour l'entreprise.
• Je ne peux pas utiliser go installpour l'installer. Ce n'est pas un problème non plus. Le pipeline de construction installe l'outil.

Cependant, il permet au serveur de compilation de ne pas avoir son espace de travail situé dans GOPATH.

Une telle approche est-elle découragée? Si oui pourquoi?

Y a-t-il d'autres effets secondaires négatifs que les deux que j'ai énumérés?

Gardez à l'esprit qu'il s'agit d'un projet privé pour une entreprise et non d'un code source ouvert public.

Détacher le projet actuel de GOPATH semble tentant, mais il faut faire attention à ne pas enfreindre les règles lorsque vous êtes sur la scène Shu

Vous n'êtes pas obligé d'utiliser GOPATH, mais vous manquez alors tous les outils utiles que vous obtenez avec la gocommande. Ils s'attendent tous à ce que le code soit dans la hiérarchie standard de GOPATH.

Vous avez mentionné go install, mais aussi go test(et l' go test -coveroutil de couverture sympa ) ne fonctionnera pas go get, ce qui vous permet de télécharger du code à distance va tout écrire sur GOPATH, vous aurez donc besoin de copier des choses.

Bien sûr, vous pouvez tout remplacer par make / scons / cmake / what et faire avancer les choses. Cela fonctionnera probablement pour votre environnement, mais c'est un travail supplémentaire qui pourrait être effectué par l' gooutil.

(disclaimer: j'aime concevoir des choses comme ça, mais je suis nouveau sur Go, je ne l'ai pas essayé en pratique)

Idée: Pourquoi pas les deux?

Si vous prenez en compte les liens symboliques, vous disposez de deux options polaires:

(A) Code en src, lié symboliquement à l'espace de travail

/
  doc/
  src/
    server/
      projectname/
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname -> ../../../src/server/projectname
      github.com/
        someone/
          library/
    bin/
    pkg/
  Makefile

(B) Code dans l'espace de travail, lié symboliquement à src

/
  doc/
  src/
    server/
      projectname -> ../../go_workspace/src/companyname/projectname
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname/
      github.com/
        someone/
          somelib/
    bin/
    pkg/
  Makefile

Je me pencherais vers "A" parce que:

• toutes vos sources vivent physiquement ensemble,
• projectname peut facilement avoir son propre repo, ou vous pouvez avoir un repo pour tout votre projet,
• vous pouvez conserver l'intégralité de la go_workspaceversion et l'initialiser via une étape de godepcréation (en utilisant ensuite la liaison symbolique du projet)

Mise à jour 2019

Vous n'avez plus besoin de stocker votre projet sous GOPATH.

Mettez-le dans un répertoire en dehors de GOPATH. Puis tapez:

go mod init github.com/youruser/yourproject

Vous serez prêt à partir.