Czy kod źródłowy projektu Go poza GOPATH jest złym pomysłem

Pracuję nad nowym projektem przy użyciu Go i wszyscy jesteśmy nowi w Go. Postępujemy zgodnie ze standardową strukturą katalogów go i mamy cały kod poniżej

$ GOPATH / src / github.com / nazwa firmy / nazwa projektu

który jest również katalogiem głównym repozytorium git

Standardowy zalecany układ ścieżki wydaje się nieco dziwny, szczególnie jeśli pracujemy nad projektem wielojęzycznym, np. Zapleczem rest / http opartym na Go oraz interfejsem html / javascript. W takim przypadku prawdopodobnie chciałbym, aby struktura mojego projektu wyglądała następująco:

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

Ale czy rzeczywiście konieczne jest umieszczenie kodu w GOPATH?

Jako próbę stworzyłem mały program, w którym kod źródłowy znajdował się poza GOPATH. Mogę z łatwością podzielić projekt na pakiety, aby mainpakiet mógł odwoływać się do foopakietu w foo/folderze przy użyciu import "./foo".

O ile widzę, są dwie rzeczy, które mnie to nie pozwalają:

• Inny kod nie może zaimportować tego kodu. Nie stanowi to problemu, ponieważ budujemy usługę specjalnie dla firmy.
• Nie mogę użyć go installdo instalacji. To też nie jest problem. Potok kompilacji instaluje narzędzie.

Pozwala jednak serwerowi kompilacji nie znajdować się w obszarze roboczym GOPATH

Czy takie podejście jest odradzane? Jeśli tak, to dlaczego?

Czy są inne negatywne skutki uboczne niż dwa wymienione przeze mnie?

Pamiętaj, że jest to prywatny projekt dla firmy, a nie publiczny kod typu open source.

Oderwanie rzeczywistego projektu od GOPATH wydaje się kuszące, ale należy być ostrożnym w łamaniu zasad, gdy jesteś na scenie Shu

Nie musisz używać GOPATH, ale tracisz wszystkie ładne narzędzia, które otrzymujesz z gopolecenia. Wszyscy oczekują, że kod będzie w standardowej hierarchii GOPATH.

Wspomniałeś go install, ale także go test(i miłe go test -covernarzędzie pokrycia) nie będzie działać go get, co pozwoli ci pobrać zdalny kod zapisuje wszystko do GOPATH, więc będziesz musiał skopiować wszystko.

Jasne, możesz zastąpić to wszystko marką / scons / cmake / cokolwiek i zrobić rzeczy i prawdopodobnie będzie to działać w twoim środowisku, ale jest to dodatkowa praca, którą może wykonać gonarzędzie.

(wyłączenie odpowiedzialności: Lubię projektować takie rzeczy, ale jestem nowy w Go, nie próbowałem tego w praktyce)

Pomysł: dlaczego nie jedno i drugie?

Istnieją dwie opcje biegunowe, jeśli weźmiesz pod uwagę dowiązanie symboliczne:

(A) Kod w src, dowiązany symbolicznie do obszaru roboczego

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

(B) Kod w obszarze roboczym, dowiązany do 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

Skłoniłbym się ku „A”, ponieważ:

• wszystkie twoje źródła żyją blisko siebie fizycznie,
• projectname może łatwo mieć własne repozytorium lub jedno repozytorium dla całego projektu,
• możesz zachować całość go_workspaceniewersjonowaną i zainicjować ją krokiem tworzenia (używając godepnastępnie symlinkowania projektu)

Aktualizacja 2019

Nie musisz już przechowywać swojego projektu GOPATH.

Po prostu umieść go w dowolnym katalogu poza GOPATH. Następnie wpisz:

go mod init github.com/youruser/yourproject

Będziesz dobrze iść.