Organizowanie projektu Go z wieloma plikami [zamknięte]

Uwaga: to pytanie jest związane z tym , ale dwa lata to bardzo długi czas w historii Go.

Jaki jest standardowy sposób organizacji projektu Go podczas programowania?

Mój projekt to jeden pakiet mypack, więc chyba wszystkie pliki .go umieściłem w mypackkatalogu.

Ale potem chciałbym to przetestować podczas programowania, więc potrzebuję przynajmniej pliku deklarującego mainpakiet, aby móc to zrobićgo run trypack.go

Jak mam to zorganizować? Czy muszę to robić za go install mypackkażdym razem, gdy chcę to wypróbować?

Polecam przejrzenie tej strony na temat pisania kodu Go

Dokumentuje zarówno sposób przyjaznej strukturyzacji projektu go build, jak i pisanie testów. Testy nie muszą być cmd przy użyciu mainpakietu. Mogą być po prostu nazwanymi funkcjami TestX jako część każdego pakietu, a następnie go testje odkryją.

Struktura sugerowana w tym łączu w twoim pytaniu jest nieco nieaktualna, teraz wraz z wydaniem Go 1. Nie będziesz już musiał umieszczać pkgkatalogu pod src. Jedyne 3 katalogi związane ze specyfikacją to 3 w katalogu głównym GOPATH: bin, pkg, src. Pod src możesz po prostu umieścić swój projekt mypack, a pod nim wszystkie twoje pliki .go, w tym mypack_test.go

go build następnie wbuduje się w pkg i bin poziom root.

Twój GOPATH może wyglądać następująco:

~/projects/
    bin/
    pkg/
    src/
      mypack/
        foo.go
        bar.go
        mypack_test.go

export GOPATH=$HOME/projects

$ go build mypack
$ go test mypack

Aktualizacja: od> = Go 1.11, system modułowy jest teraz standardową częścią oprzyrządowania, a koncepcja GOPATH jest już prawie przestarzała.

jdi ma właściwe informacje dotyczące korzystania z GOPATH. Dodałbym, że jeśli zamierzasz mieć również plik binarny, możesz chcieć dodać jeden dodatkowy poziom do katalogów.

~/projects/src/
    myproj/
        mypack/
            lib.go
            lib_test.go
            ...
        myapp/
            main.go

uruchomiony go build myproj/mypackzbuduje mypackpakiet wraz z jego zależnościami działa go build myproj/myappzbuduje myappbinarny wraz z nim w zależności, która prawdopodobnie zawiera się mypackbiblioteka.

Przebadałem wiele projektów Go i istnieje spora różnorodność. Możesz powiedzieć, kto pochodzi z C, a kto z Javy, ponieważ pierwszy zrzut prawie wszystko w katalogu głównym projektów w mainpakiecie, a drugi zwykle umieszcza wszystko wsrc katalogu. Jednak żadne nie jest optymalne. Każda z nich ma konsekwencje, ponieważ wpływa na ścieżki importu i sposób, w jaki inni mogą z nich korzystać ponownie.

Aby uzyskać najlepsze wyniki, opracowałem następujące podejście.

myproj/
  main/
    mypack.go
  mypack.go

Gdzie mypack.gojest package mypacki main/mypack.gojest (oczywiście) package main.

Jeśli potrzebujesz dodatkowych plików pomocniczych, masz dwie możliwości. Albo zachowaj je wszystkie w katalogu głównym, albo umieść prywatne pliki pomocy w libpodkatalogu. Na przykład

myproj/
  main/
    mypack.go
  myextras/
    someextra.go
  mypack.go
  mysupport.go

Lub

myproj.org/
  lib/
    mysupport.go
    myextras/
      someextra.go
  main/
    mypack.go
  mypage.go

Pliki umieść w libkatalogu tylko wtedy, gdy nie są przeznaczone do zaimportowania przez inny projekt. Innymi słowy, jeśli są to prywatne pliki wsparcia. Taki jest pomysł posiadanialib - w celu oddzielenia interfejsów publicznych od prywatnych.

Robienie tego w ten sposób da ci dobrą ścieżkę importu, myproj.org/mypackaby ponownie wykorzystać kod w innych projektach. Jeśli używasz libwtedy wewnętrzne pliki pomocnicze będzie miał ścieżkę importu, który wskazuje, że myproj.org/lib/mysupport.

Budując projekt, użyj main/mypacknp go build main/mypack. Jeśli masz więcej niż jeden plik wykonywalny, możesz również oddzielić je od siebie mainbez konieczności tworzenia osobnych projektów. np . main/myfoo/myfoo.goi main/mybar/mybar.go.

Bardzo przydatne jest zrozumienie, jak zorganizować kod w Golang w tym rozdziale http://www.golang-book.com/11 książki napisanej przez Caleba Doxseya

Wydaje się, że nie ma standardowego sposobu organizowania projektów Go, ale https://golang.org/doc/code.html określa najlepszą praktykę dla większości projektów. Odpowiedź jdi jest dobra, ale jeśli używasz github lub bitbucket i masz także dodatkowe biblioteki, powinieneś utworzyć następującą strukturę:

~/projects/
bin/
pkg/
src/
  github.com/
    username/
        mypack/
            foo.go
            bar.go
            mypack_test.go
        mylib/
            utillib.go
            utillib_test.go

Robiąc to w ten sposób, możesz mieć osobne repozytorium dla mylib, które może być używane do innych projektów i może być odzyskane przez „go get”. Twój projekt mypack może zaimportować bibliotekę za pomocą „github.com/username/mylib”. Po więcej informacji:

http://www.alexvictorchan.com/2014/11/06/go-project-structure/

Przechowuj pliki w tym samym katalogu i używaj package mainwe wszystkich plikach.

myproj/
   your-program/
      main.go
      lib.go

Następnie uruchomić:

~/myproj/your-program$ go build && ./your-program

Zobaczmy, w jaki sposób go get repository_remote_urlpolecenie zarządza strukturą projektu $GOPATH. Jeśli to zrobimy go get github.com/gohugoio/hugo, sklonuje repozytorium pod

$ GOPATH / src / repository_remote / nazwa_użytkownika / nazwa_projektu

$ GOPATH / src / github.com/gohugoio/hugo

To dobry sposób na utworzenie początkowej ścieżki projektu . Teraz zbadajmy, jakie są typy projektów i jak są zorganizowane ich wewnętrzne struktury. Wszystkie projekty golang w społeczności można podzielić na kategorie

• Libraries (brak wykonywalnych plików binarnych)
• Single Project (zawiera tylko 1 plik wykonywalny)
• Tooling Projects (zawiera wiele wykonywalnych plików binarnych)

Zasadniczo pliki projektów golang można spakować zgodnie z dowolnymi zasadami projektowania, takimi jak DDD , POD

Większość dostępnych projektów go jest zgodna z tym pakietowym projektem

Projektowanie zorientowane na pakiet zachęca dewelopera do utrzymywania implementacji tylko w swoich własnych pakietach, innych niż /internalpakiet, którego te pakiety nie mogą się ze sobą komunikować

Biblioteki

• Projekty takie jak sterowniki baz danych , qt można umieścić w tej kategorii.
• Niektóre biblioteki, takie jak kolor , teraz płaską strukturę bez żadnych innych pakietów.
• Większość tych projektów bibliotecznych zarządza pakietem zwanym wewnętrznym .
• /internal Pakiet służy głównie do ukrywania implementacji przed innymi projektami.
• Nie ma żadnych wykonywalnych plików binarnych, więc żadne pliki nie zawierają głównego func .

 ~/$GOPATH/
    bin/
    pkg/
    src/
      repository_remote/
        user_name/
            project_name/
              internal/
              other_pkg/

Pojedynczy projekt

• Projekty takie jak hugo , etcd mają jeden główną na poziomie root i.
• Celem jest wygenerowanie jednego pliku binarnego

Projekty narzędzi

• Projekty takie jak kubernetes , go-ethereum mają wiele głównych funkcji zorganizowanych w pakiecie o nazwie cmd
• cmd/ pakiet zarządza liczbą plików binarnych (narzędzi), które chcemy zbudować

 ~/$GOPATH/
    bin/
    pkg/
    src/
      repository_remote/
        user_name/
            project_name/
              cmd/
                binary_one/
                   main.go
                binary_two/
                   main.go
                binary_three/
                   main.go
              other_pkg/