web-dev-qa-db-fra.com

Organisation d'un projet Go comportant plusieurs fichiers

Remarque: cette question est liée à celle-ci , mais deux ans, cela fait très longtemps dans l’historique de Go.

Quelle est la méthode standard pour organiser un projet Go pendant le développement?

Mon projet est un package unique mypack, donc je suppose que je mets tous les fichiers .go dans un répertoire mypack.

Mais ensuite, je voudrais le tester pendant le développement, donc il me faut au moins un fichier déclarant le paquetage main, pour pouvoir faire go run trypack.go

Comment dois-je organiser cela? Dois-je faire go install mypack chaque fois que je veux l'essayer?

go
227
Blacksad

Je recommanderais de revoir cette page sur Comment écrire un code Go

Il explique à la fois comment structurer votre projet de manière conviviale go build et comment écrire des tests. Il n'est pas nécessaire que les tests soient une cmd utilisant le package main. Il peut simplement s'agir de fonctions nommées TestX dans chaque paquet, puis go test les détectera.

La structure suggérée dans ce lien dans votre question est un peu dépassée, maintenant avec la publication de Go 1. Vous n’auriez plus besoin de placer un répertoire pkg sous src. Les 3 seuls répertoires liés aux spécifications sont les 3 situés à la racine de votre GOPATH: bin, pkg, src. Sous src, vous pouvez simplement placer votre projet mypack et sous celui-ci se trouvent tous vos fichiers .go, y compris mypack_test.go.

go build sera ensuite intégré à la racine pkg et bin.

Donc, votre GOPATH pourrait ressembler à ceci:

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

export GOPATH=$HOME/projects

$ go build mypack
$ go test mypack

Mise à jour: à partir de> = Go 1.11, le système Module fait désormais partie intégrante de l'outillage et le concept GOPATH est sur le point de devenir obsolète.

166
jdi

jdi a les bonnes informations concernant l’utilisation de GOPATH. J'ajouterais que si vous avez également l'intention d'utiliser un fichier binaire, vous voudrez peut-être ajouter un niveau supplémentaire aux 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. Si vous exécutez go build myproj/myapp, vous construirez le binaire myapp avec ses dépendances, ce qui inclut probablement la bibliothèque mypack.

59
Jeremy Wall

J'ai étudié plusieurs projets de Go et il y a pas mal de variations. Vous pouvez en quelque sorte savoir qui vient de C et qui vient de Java, le premier vidant tout dans le répertoire racine du projet dans un paquetage main, et ce dernier ayant tendance à tout mettre dans un src répertoire. Ni est optimale cependant. Chacune a des conséquences car elle affecte les chemins d'importation et la manière 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 le choix. Conservez-les tous dans le répertoire racine ou mettez les fichiers privés 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

Ne placez les fichiers dans un répertoire lib que s'ils ne sont pas destinés à être importés par un autre projet. En d’autres termes, s’ils sont privés fichiers de support. C’est l’idée qui sous-tend la lib - de séparer les interfaces publique des interfaces privées.

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

Lors de la construction du projet, utilisez main/mypack, par exemple. go build main/mypack. Si vous avez plusieurs exécutables, vous pouvez également séparer ceux-ci sous main sans avoir à créer des projets séparés. par exemple. main/myfoo/myfoo.go et main/mybar/mybar.go.

48
trans

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

21
edap

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. La réponse de jdi est bonne, mais si vous utilisez github ou bitbucket et que vous disposez également de bibliothèques supplémentaires, 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 procédant ainsi, vous pouvez avoir un référentiel séparé pour mylib qui peut être utilisé pour d’autres projets et qui peut être récupéré par "go get". Votre projet mypack peut importer votre bibliothèque en utilisant "github.com/nomutilisateur/mylib". Pour plus d'informations:

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

12
alexdotc

Conservez les fichiers dans le même répertoire et utilisez package main dans tous les fichiers.

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

Puis lancez:

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

Explorons 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 va cloner le dépôt sous

$ GOPATH/src/ repository_remote/nom_utilisateur/nom_projet

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

C'est une bonne façon de créer votre chemin de projet initial . Maintenant, explorons quels sont les types de projets existants et comment leurs structures internes sont organisées. 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 binaire exécutable)
  • Tooling Projects (contient plusieurs fichiers binaires exécutables)

En règle générale, les fichiers de projet golang peuvent être regroupés sous n’importe quel principe de conception tel que DDD , POD

La plupart des projets disponibles suivent ceci Conception orientée package

Package Oriented Design encourage le développeur à conserver l'implémentation uniquement dans ses propres packages, autres que le package /internal que ces packages ne peuvent pas communiquer entre eux.

Bibliothèques

  • Des projets tels que drivers de base de données , qt peuvent être classés dans cette catégorie.
  • Certaines bibliothèques telles que color , now suivent une structure plate sans aucun autre package.
  • La plupart de ces projets de bibliothèque gèrent un paquet appelé internal .
  • Le package /internal est principalement utilisé pour masquer l'implémentation des autres projets.
  • N'ayant aucun fichier binaire exécutable, aucun fichier contenant le principal func .
 ~/$GOPATH/
    bin/
    pkg/
    src/
      repository_remote/
        user_name/
            project_name/
              internal/
              other_pkg/

Projet unique

  • Des projets tels que hugo , etcd ont une fonction unique au niveau racine et.
  • La cible est de générer un seul binaire

Projets d'outillage

  • Des projets tels que kubernetes , go-ethereum ont plusieurs fonctions principales organisées sous un paquet appelé cmd
  • Le paquet cmd/ gère le nombre de fichiers 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/
4
noelyahan