Как я могу разрешить зависимости во вложенном двоичном приложении в проекте Go? - PullRequest
0 голосов
/ 14 февраля 2019

Это звучит глупо, но я сейчас пытаюсь собрать свой новый проект golang и застрял со следующей ошибкой

не могу загрузить пакет: package github.com/kuskmen/yamq / cmd / yamq-client: найдены пакеты main (main.go) и yamqclient (yamq-client.go) в C: \ projects \ yamq \ cmd \ yamq-client

Я знаю этоисправление должно быть простым, но я из .NET, и у меня до сих пор нет опыта в проектах Go и его модели разрешения зависимостей, следовательно, борьба.

Структура моего проекта выглядит так

/yamq
    /cmd
        /yamq-client          // yamq client application binary
            main.go           // package main
            yamq-client.go    // package yamqclient
        /yamq-server          // yamq server application binary
            main.go           // package main
            yamq-server.go    // package yamqserver
    go.mod                // contains only "module github.com/kuskmen/yamq" for now
    ... // some library files that will probably be moved to /shared folder

пока все хорошо, когда я делаю go build в крайнем каталоге (/ yamq), он успешно строится (или, по крайней мере, не показывает никаких ошибок), но когда я пытаюсь создать либо yamq-client, либо yamq-server двоичные файлыЯ получаю вышеупомянутую ошибку, и каждый раз, когда я пытаюсь зайти в нее или найти что-то полезное, я получаю старую статью или ответ, который датируется 2013–2016 годами, в котором предлагается что-то о $GOPATH и т. Д., Что не должно быть здесь, поскольку яTПытаюсь использовать модули Go.

Помогите одному из разработчиков .NET присоединиться к сообществу Go, объяснив ему, как именно работают модули, потому что я нашел это и это бесполезным или по крайней мереЯ упускаю суть, заранее спасибо!

Ответы [ 2 ]

0 голосов
/ 14 февраля 2019

В продолжение моего комментария выше:

С https://golang.org/doc/code.html:

  • Программисты Go обычно хранят весь свой код Go в одном рабочем пространстве.
  • Рабочая область содержит множество репозиториев контроля версий (например, управляемых Git).
  • Каждый репозиторий содержит один или несколько пакетов.
  • Каждый пакет состоит из одного или нескольких исходных файлов Go в один каталог .
  • Путь к каталогу пакета определяет путь его импорта.
0 голосов
/ 14 февраля 2019

Для вашего проекта я бы сделал что-то вроде этого:

$ tree
.
├── clientlib
│   └── lib.go
├── cmd
│   ├── client
│   │   └── main.go
│   └── server
│       └── main.go
├── go.mod
└── serverlib
    └── lib.go

5 directories, 5 files

$ cat go.mod
module myproject.com

Имя модуля произвольно (может быть github.com/yourname/yourproject).

Для стороны сервера:

$ cat serverlib/lib.go 
package serverlib

import "fmt"

func Hello() {
    fmt.Println("Hello from serverlib.Hello")
}

$ cat cmd/server/main.go 
package main

import (
    "fmt"

    "myproject.com/serverlib"
)

func main() {
    fmt.Println("Running server")
    serverlib.Hello()
}

И теперь мы можем построить и запустить его:

$ go build -o server cmd/server/main.go 
$ ./server
Running server
Hello from serverlib.Hello

Клиентская сторона выглядит симметрично.

Варианты: вы можете назвать .go файлы в cmd/... по их действительным двоичным именам - как server.go и client.go.Пакет в каждом по-прежнему main, но затем go build создает исполняемый файл с именем файла (без .go), без необходимости -o явно.

...