it-swarm.com.de

Organisieren eines Go-Projekts mit mehreren Dateien

Hinweis: Diese Frage bezieht sich auf diese , aber zwei Jahre sind eine sehr lange Zeit in der Go-Geschichte.

Was ist die Standardmethode, um ein Go-Projekt während der Entwicklung zu organisieren?

Mein Projekt ist ein einzelnes Paket mypack, also habe ich wohl alle .go-Dateien in ein mypack -Verzeichnis gestellt.

Aber dann würde ich es gerne während der Entwicklung testen, also brauche ich mindestens eine Datei, die das main -Paket deklariert, damit ich go run trypack.go

Wie soll ich das organisieren? Muss ich go install mypack jedes Mal, wenn ich es versuchen möchte?

227
Blacksad

Ich würde empfehlen, diese Seite am How to Write Go Code zu lesen

Es dokumentiert sowohl die Strukturierung Ihres Projekts in einem go build freundliche Art und Weise, und auch, wie man Tests schreibt. Tests müssen keine cmd sein, die das main -Paket verwenden. Sie können einfach TestX-benannte Funktionen als Teil jedes Pakets sein und dann go test wird sie entdecken.

Die in diesem Link in Ihrer Frage vorgeschlagene Struktur ist mit der Veröffentlichung von Go 1 etwas veraltet. Sie müssten kein pkg -Verzeichnis mehr unter src platzieren. Die einzigen 3 spezifikationsbezogenen Verzeichnisse sind die 3 im Stammverzeichnis Ihres GOPATH: bin, pkg, src. Unter src können Sie einfach Ihr Projekt mypack platzieren. Darunter befinden sich alle Ihre .go-Dateien, einschließlich der Datei mypack_test.go

go build wird dann in die Root-Ebene pkg und bin eingebaut.

Dein GOPATH könnte also so aussehen:

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

export GOPATH=$HOME/projects

$ go build mypack
$ go test mypack

Update: Ab> = Go 1.11 ist das Modul System nun ein Standardbestandteil der Werkzeuge, und das GOPATH-Konzept ist nahezu veraltet.

166
jdi

jdi hat die richtigen Informationen zur Verwendung von GOPATH. Ich würde hinzufügen, dass, wenn Sie beabsichtigen, auch eine Binärdatei zu haben, Sie den Verzeichnissen möglicherweise eine zusätzliche Ebene hinzufügen möchten.

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

wenn Sie go build myproj/mypack ausführen, wird das mypack-Paket zusammen mit den Abhängigkeiten erstellt. Wenn Sie go build myproj/myapp ausführen, wird die myapp-Binärdatei zusammen mit den Abhängigkeiten erstellt, die wahrscheinlich die mypack Bibliothek.

59
Jeremy Wall

Ich habe eine Reihe von Go-Projekten studiert und es gibt einige Variationen. Man kann sagen, wer von C kommt und wer von Java kommt, da der erste Speicherauszug fast alles im Stammverzeichnis des Projekts in einem main -Paket enthält und letzterer dazu neigt, alles in ein src Verzeichnis. Beides ist jedoch nicht optimal. Jede hat Konsequenzen, da sie sich auf Importpfade auswirken und darauf, wie andere sie wiederverwenden können.

Um die besten Ergebnisse zu erzielen, habe ich den folgenden Ansatz ausgearbeitet.

myproj/
  main/
    mypack.go
  mypack.go

Wo mypack.go ist package mypack und main/mypack.go ist (offensichtlich) package main.

Wenn Sie zusätzliche Unterstützungsdateien benötigen, haben Sie zwei Möglichkeiten. Bewahren Sie sie entweder alle im Stammverzeichnis auf oder legen Sie private support-Dateien in einem lib -Unterverzeichnis ab. Z.B.

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

Oder

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

Legen Sie die Dateien nur in einem Verzeichnis lib ab, wenn sie nicht von einem anderen Projekt importiert werden sollen. Mit anderen Worten, wenn es sich um private Unterstützungsdateien handelt. Das ist die Idee, die dahinter steckt, lib - öffentliche von privaten Schnittstellen zu trennen.

Wenn Sie auf diese Weise vorgehen, erhalten Sie einen netten Importpfad, myproj.org/mypack, um den Code in anderen Projekten wiederzuverwenden. Wenn Sie lib verwenden, haben interne Unterstützungsdateien einen entsprechenden Importpfad. myproj.org/lib/mysupport.

Verwenden Sie beim Erstellen des Projekts main/mypack, z.B. go build main/mypack. Wenn Sie mehr als eine ausführbare Datei haben, können Sie diese auch unter main trennen, ohne separate Projekte erstellen zu müssen. z.B. main/myfoo/myfoo.go und main/mybar/mybar.go.

48
trans

Ich finde es sehr nützlich zu verstehen, wie man Code in Golang dieses Kapitel http://www.golang-book.com/11 des von Caleb Doxsey geschriebenen Buches organisiert

21
edap

Es scheint keine Standardmethode zum Organisieren von Go-Projekten zu geben, aber https://golang.org/doc/code.html gibt eine bewährte Methode für die meisten Projekte an. Die Antwort von jdi ist gut, aber wenn Sie Github oder Bitbucket verwenden und über zusätzliche Bibliotheken verfügen, sollten Sie die folgende Struktur erstellen:

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

Auf diese Weise können Sie ein separates Repository für mylib einrichten, das für andere Projekte verwendet und mit "go get" abgerufen werden kann. Ihr Mypack-Projekt kann Ihre Bibliothek mit "github.com/username/mylib" importieren. Für mehr Informationen:

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

12
alexdotc

Bewahren Sie die Dateien im selben Verzeichnis auf und verwenden Sie package main in allen Dateien.

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

Dann renne:

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

Lassen Sie uns erforschen, wie die go get repository_remote_url Befehl verwaltet die Projektstruktur unter $GOPATH. Wenn wir ein go get github.com/gohugoio/hugo Es wird das Repository unter klonen

$ GOPATH/src/ Repository_Remote/Benutzername/Projektname


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

Dies ist ein guter Weg, um Ihren anfänglichen Projektpfad zu erstellen. Lassen Sie uns nun untersuchen, welche Projekttypen es gibt und wie ihre inneren Strukturen organisiert sind. Alle Golang-Projekte in der Community können unter kategorisiert werden

  • Libraries (keine ausführbaren Binärdateien)
  • Single Project (enthält nur 1 ausführbare Binärdatei)
  • Tooling Projects (enthält mehrere ausführbare Binärdateien)

Im Allgemeinen können Golang-Projektdateien unter beliebigen Entwurfsprinzipien gepackt werden, z. B. DDD , POD

Die meisten verfügbaren go-Projekte folgen diesem Package Oriented Design

Package Oriented Design Ermutigen Sie den Entwickler, die Implementierung nur in seinen eigenen Paketen zu belassen, mit Ausnahme des /internal package Diese Pakete können nicht miteinander kommunizieren


Bibliotheken

  • Projekte wie Datenbanktreiber , qt können in diese Kategorie eingeordnet werden.
  • Einige Bibliotheken wie color , now folgen einer flachen Struktur ohne andere Pakete.
  • Die meisten dieser Bibliotheksprojekte verwalten ein Paket mit dem Namen internal .
  • /internal package wird hauptsächlich verwendet, um die Implementierung vor anderen Projekten zu verbergen.
  • Keine ausführbaren Binärdateien, daher keine Dateien mit der main func .

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

Einzelprojekt

  • Projekte wie hugo , etcd haben eine einzelne Hauptfunktion im Root-Level und.
  • Ziel ist es, eine einzige Binärdatei zu generieren

Werkzeugprojekte

  • Projekte wie kubernetes , go-ethereum haben mehrere Hauptfunktionen, die unter einem Paket namens cmd
  • cmd/ package verwaltet die Anzahl der zu erstellenden Binärdateien (Tools)

 ~/$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/
4
noelyahan