Organizando um projeto Go de vários arquivos [fechado]

Nota: esta pergunta está relacionada a esta , mas dois anos são muito longos na história do Go.

Qual é a maneira padrão de organizar um projeto Go durante o desenvolvimento?

Meu projeto é um pacote único mypack, então acho que coloquei todos os arquivos .go em um mypackdiretório.

Mas então, eu gostaria de testá-lo durante o desenvolvimento, para que eu precise de pelo menos um arquivo que declare o mainpacote, para que eu possa fazergo run trypack.go

Como devo organizar isso? Preciso fazer isso go install mypacktoda vez que quiser experimentar?

Eu recomendaria revisar esta página em Como escrever código Go

Ele documenta como estruturar seu projeto de go buildmaneira amigável e também como escrever testes. Os testes não precisam ser um cmd usando o mainpacote. Eles podem simplesmente ser funções nomeadas do TestX como parte de cada pacote e depois as go testdescobrirão.

A estrutura sugerida nesse link na sua pergunta está um pouco desatualizada, agora com o lançamento do Go 1. Você não precisa mais colocar um pkgdiretório src. Os únicos 3 diretórios relacionados a especificações são os 3 na raiz do seu GOPATH: bin, pkg, src. Abaixo do src, você pode simplesmente colocar o seu projeto mypacke, por baixo, todos os seus arquivos .go, incluindo o mypack_test.go

go build irá então construir no nível raiz pkg e bin.

Portanto, seu GOPATH pode ficar assim:

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

export GOPATH=$HOME/projects

$ go build mypack
$ go test mypack

Atualização: a partir de> = Ir 1.11, o sistema Module é agora uma parte padrão do ferramental e o conceito GOPATH está quase se tornando obsoleto.

jdi tem as informações corretas sobre o uso de GOPATH. Eu acrescentaria que, se você pretende ter um binário, também poderá adicionar um nível adicional aos diretórios.

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

running go build myproj/mypackirá construir o mypackpacote junto com suas dependências running go build myproj/myappirá construir o myappbinário junto com suas dependências que provavelmente incluem a mypackbiblioteca.

Estudei vários projetos Go e há uma boa variação. Você pode dizer quem vem de C e quem vem de Java, pois o primeiro despeja quase tudo no diretório raiz do projeto em um mainpacote e o último tende a colocar tudo em um srcdiretório. Nem é ideal, no entanto. Cada um tem consequências porque afeta os caminhos de importação e como os outros podem reutilizá-los.

Para obter os melhores resultados, elaborei a seguinte abordagem.

myproj/
  main/
    mypack.go
  mypack.go

Onde mypack.goestá package mypacke main/mypack.goestá (obviamente) package main.

Se você precisar de arquivos de suporte adicionais, terá duas opções. Mantenha todos eles no diretório raiz ou coloque os arquivos de suporte privado em um libsubdiretório. Por exemplo

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

Coloque os arquivos em um libdiretório apenas se eles não forem importados por outro projeto. Em outras palavras, se eles são arquivos de suporte particulares . Essa é a idéia por trás de ter lib- para separar interfaces públicas de privadas.

Fazer as coisas dessa maneira fornecerá um bom caminho de importação myproj.org/mypackpara reutilizar o código em outros projetos. Se você usar lib, os arquivos de suporte interno terão um caminho de importação indicativo disso myproj.org/lib/mysupport,.

Ao construir o projeto, use main/mypack, por exemplo go build main/mypack. Se você tiver mais de um executável, também poderá separá-los mainsem precisar criar projetos separados. por exemplo, main/myfoo/myfoo.goe main/mybar/mybar.go.

Acho muito útil entender como organizar o código em Golang neste capítulo http://www.golang-book.com/11 do livro escrito por Caleb Doxsey

Não parece haver uma maneira padrão de organizar projetos Go, mas https://golang.org/doc/code.html especifica uma prática recomendada para a maioria dos projetos. A resposta do jdi é boa, mas se você usa o github ou o bitbucket e também possui bibliotecas adicionais, deve criar a seguinte estrutura:

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

Fazendo dessa maneira, você pode ter um repositório separado para mylib que pode ser usado para outros projetos e pode ser recuperado por "vá buscar". Seu projeto mypack pode importar sua biblioteca usando "github.com/username/mylib". Para maiores informações:

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

Mantenha os arquivos no mesmo diretório e use package mainem todos os arquivos.

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

Então corra:

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

Vamos explorar como o go get repository_remote_urlcomando gerencia a estrutura do projeto $GOPATH. Se fizermos um, go get github.com/gohugoio/hugoele clonará o repositório em

$ GOPATH / src / repository_remote / user_name / project_name

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

Essa é uma boa maneira de criar o caminho do projeto inicial . Agora vamos explorar quais são os tipos de projeto e como suas estruturas internas são organizadas. Todos os projetos golang na comunidade podem ser classificados em

• Libraries (sem binários executáveis)
• Single Project (contém apenas 1 binário executável)
• Tooling Projects (contém vários binários executáveis)

Geralmente, os arquivos do projeto golang podem ser empacotados sob quaisquer princípios de design , como DDD , POD

A maioria dos projetos disponíveis segue este Design Orientado a Pacotes

O Design Orientado a Pacotes incentiva o desenvolvedor a manter a implementação apenas dentro de seus próprios pacotes, além do /internalpacote que esses pacotes não podem se comunicar.

Bibliotecas

• Projetos como drivers de banco de dados , qt podem ser colocados nessa categoria.
• Algumas bibliotecas, como cores , agora seguem uma estrutura plana sem outros pacotes.
• A maioria desses projetos de biblioteca gerencia um pacote chamado interno .
• /internal O pacote é usado principalmente para ocultar a implementação de outros projetos.
• Não possui binários executáveis; portanto, não há arquivos que contenham a função principal .

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

Projeto único

• Projetos como hugo , etcd têm uma única função principal no nível raiz e.
• O objetivo é gerar um único binário

Projetos de Ferramentas

• Projetos como kubernetes , go-ethereum têm várias funções principais organizadas sob um pacote chamado cmd
• cmd/ O pacote gerencia o número de binários (ferramentas) que queremos construir

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