Organización de un proyecto Go de varios archivos

Jdi tiene la información correcta sobre el uso de GOPATH. Yo añadiría que si usted tiene la intención de tener un binario, así que es posible que desee añadir un nivel adicional a los directorios.

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

Ejecutando go build myproj/mypack construirá el paquete mypack junto con sus dependencias ejecutar go build myproj/myapp construirá el binario myapp junto con sus dependencias que probablemente incluyen la biblioteca mypack.

He estudiado una serie de proyectos Go y hay un poco de variación. Puede decir quién viene de C y quién viene de Java, ya que el primero volcó casi todo en el directorio raíz de proyectos en un paquete main, y el segundo tiende a poner todo en un directorio src. Sin embargo, ninguno es óptimo. Cada uno tiene consecuencias porque afectan las rutas de importación y cómo otros pueden reutilizarlas.

Para obtener los mejores resultados he elaborado lo siguiente enfoque.

myproj/
  main/
    mypack.go
  mypack.go

Donde mypack.go es package mypack y main/mypack.go es (obviamente) package main.

Si necesita archivos de soporte adicionales, tiene dos opciones. Manténgalos todos en el directorio raíz, o ponga archivos de soporte privados en un subdirectorio lib. Por ejemplo,

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

O

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

Solo coloque los archivos en un directorio lib si no están destinados a ser importados por otro proyecto. En otras palabras, si son archivos de soporte privados. Esa es la idea detrás teniendo lib separate para separar las interfaces públicas de las privadas.

Hacer las cosas de esta manera le dará una ruta de importación agradable, myproj.org/mypack para reutilizar el código en otros proyectos. Si usa lib entonces los archivos de soporte internos tendrán una ruta de importación que es indicativa de eso, myproj.org/lib/mysupport.

Al construir el proyecto, use main/mypack, por ejemplo go build main/mypack. Si tiene más de un ejecutable, también puede separarlos bajo main sin tener que crear proyectos separados. por ejemplo, main/myfoo/myfoo.go y main/mybar/mybar.go.

Me parece muy útil para entender cómo organizar el código en Golang este capítulo http://www.golang-book.com/11 del libro escrito por Caleb Doxsey

No parece haber una forma estándar de organizar proyectos Go pero https://golang.org/doc/code.html especifica una buena práctica para la mayoría de los proyectos. la respuesta de jdi es buena, pero si usas github o bitbucket y también tienes bibliotecas adicionales, deberías crear la siguiente estructura:

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

Al hacerlo de esta manera, puede tener un repositorio separado para mylib que puede ser utilizado para otros proyectos y puede ser recuperado por "go get". Tu proyecto mypack puede importar su biblioteca usando "github.com/username/mylib". Para más información:

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

Mantenga los archivos en el mismo directorio y use package main en todos los archivos.

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

Luego ejecute:

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

Vamos a explorar cómo el comando go get repository_remote_url administra la estructura del proyecto bajo $GOPATH. Si hacemos un go get github.com/gohugoio/hugo clonará el repositorio bajo

GOP GOPATH/src/repository_remote / user_name / project_name

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

Esta es una buena manera de crear su ruta inicial del proyecto. Ahora vamos a explorar cuáles son los tipos de proyectos por ahí y cómo sus estructuras internas son organizado. Todos los proyectos de golang en la comunidad se pueden clasificar en

• Libraries (sin binarios ejecutables)
• Single Project (contiene solo 1 binario ejecutable)
• Tooling Projects (contiene varios binarios ejecutables)

Generalmente los archivos del proyecto golang se pueden empaquetar bajo cualquier principio de diseño como DDD, POD

La mayoría de los proyectos go disponibles siguen este Orientado a paquetes Diseño

Diseño orientado a paquetes anime al desarrollador a mantener la implementación solo dentro de sus propios paquetes, aparte del paquete /internal esos paquetes no pueden comunicarse entre sí

Bibliotecas

• Proyectos como controladores de base de datos, qt puede poner en esta categoría.
• Algunas bibliotecas como color, ahora sigue una estructura plana sin ningún otro paquete.
• La mayoría de estos proyectos de bibliotecas gestionan un paquete llamado internal.
• /internal package se usa para mantener archivos go que usan otros paquetes múltiples dentro del proyecto.
• no tiene ningún binarios ejecutables, así que no hay archivos que contiene el principal func.

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

Proyecto único

• Proyectos como hugo, etcd tiene un func principal único en el nivel raíz y.
• El objetivo es generar un único binario

Proyectos de herramientas

• Proyectos como kubernetes, go-ethereum tiene múltiples func principal organizado bajo un paquete llamado cmd
• cmd/ el paquete gestiona el número de binarios (herramientas) que queremos compilar

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