Organisation d'un projet de Go à plusieurs fichiers

jdi a le droit de l'information concernant l'utilisation de GOPATH . Je voudrais ajouter que si vous avez l'intention d'avoir un binaire ainsi vous pouvez ajouter un niveau supplémentaire pour les répertoires.

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

exécuter go build myproj/mypack construira le paquet mypack avec ses dépendances l'exécution de go build myproj/myapp construira le binaire myapp avec ses dépendances qui inclut probablement la bibliothèque mypack .

j'ai étudié un certain nombre de projets Go et il ya un peu de variation. Vous pouvez en quelque sorte dire qui vient de C et qui vient de Java, car le premier dump à peu près tout dans le répertoire racine des projets dans un paquet main , et le second a tendance à tout mettre dans un répertoire src . Ni est optimal. Chacune a des conséquences parce qu'elle affecte les voies d'importation et la façon dont les autres peuvent les réutiliser.

Pour obtenir les meilleurs résultats J'ai élaboré l'approche suivante.

myproj/
  main/
    mypack.go
  mypack.go

où mypack.go est package mypack et main/mypack.go est (évidemment) package main .

si vous avez besoin de fichiers de support supplémentaires, vous avez deux choix. Soit vous les gardez tous dans le répertoire racine, soit vous mettez privé fichiers de support dans un sous-répertoire lib . Par exemple:

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

ou

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

Seulement mis les fichiers dans un lib répertoire s'ils ne sont pas destinés à être importés par un autre projet. En d'autres termes, s'ils sont privé fichiers de soutien. C'est l'idée d'avoir lib --pour séparer les interfaces publiques des privées.

Faire les choses de cette façon vous donnera un bon chemin d'importation, myproj.org/mypack pour réutiliser le code dans d'autres projets. Si vous utilisez lib alors les fichiers de support internes auront un chemin d'importation qui est myproj.org/lib/mysupport .

pour la construction du projet, utilisez main/mypack , p.ex. go build main/mypack . Si vous avez plus d'un exécutable, Vous pouvez également séparer ceux sous main sans avoir à créer des projets séparés. par exemple main/myfoo/myfoo.go et main/mybar/mybar.go .

je trouve très utile pour comprendre comment organiser le code dans Golang ce chapitre http://www.golang-book.com/11 du livre écrit par Caleb Doxsey

il ne semble pas y avoir de méthode standard pour organiser les projets Go mais https://golang.org/doc/code.html spécifie une meilleure pratique pour la plupart des projets. jdi réponse est bonne, mais si vous utilisez github ou bitbucket et vous avez d'autres bibliothèques, vous devez créer la structure suivante:

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

En le faisant de cette façon, vous pouvez avoir un référentiel pour mylib qui peut être utilisé pour d'autres projets et peuvent être récupérées par "aller chercher". Votre projet mypack peut importer votre bibliothèque en utilisant "github.com/username/mylib". Pour plus d'informations:

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

Conserver les fichiers dans le même répertoire et utiliser package main dans tous les fichiers.

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

puis exécuter:

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

voyons comment la commande go get repository_remote_url gère la structure du projet sous $GOPATH . Si nous faisons un go get github.com/gohugoio/hugo il clonera le dépôt sous

$GOPATH / src/ repository_remote/user_name/project_name

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

C'est une bonne façon de créer votre chemin initial du projet . Maintenant, nous allons explorer quels sont les types de projet là-bas et comment leurs structures internes sont organisés. Tous les projets de golang dans la communauté peuvent être classés sous

• Libraries (pas de fichiers binaires exécutables)
• Single Project (contient seulement 1 exécutable binaire)
• Tooling Projects (contient plusieurs exécutables binaires))

généralement, les dossiers de projet golang peuvent être empaquetés sous n'importe quels principes de conception tels que DDD , POD

la plupart des projets go disponibles suit ce Package Oriented Design

Package Oriented Design implémentation seulement à l'intérieur de ses propres paquets, à l'exception du paquet /internal . ces paquets ne peuvent pas communiquer entre eux.

bibliothèques

• les projets tels que les pilotes de base de données , qt peuvent mettre dans cette catégorie.
• certaines bibliothèques telles que couleur , maintenant suit a structure plate sans autres paquets.
• la plupart de ces projets de bibliothèque gère un paquet appelé interne .
• /internal package est utilisé pour maintenir go de fichiers qui utilise d'autres de plusieurs paquets à l'intérieur du projet.
• N'ont pas de binaires exécutables, donc pas de fichiers qui contiennent le principal func .

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

Projet Unique

• projets tels que hugo , etcd a un unique fonction principale dans le niveau de racine et.
• l'Objectif est de générer un binaire

Outillage Projets

• projets tels que kubernetes , de l'ethereum a multiple principal func organisé en vertu d'un paquet appelé cmd
• cmd/ paquet gère le nombre de binaires (outils) que nous voulons construire

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