10

我是新来的模块,并且正在将它们用于一个新项目中,我试图在此处描述的结构之后对其进行建模

这是我的目录结构的示例:

.
├── cmd
│   └── app_name
│       └── main.go
├── go.mod
├── go.sum
├── internal
│   └── bot
│       └── bot.go
└── pkg
    ├── website_name
    │   ├── client.go
    │   ├── client.options.go
    │   ├── server.go
    │   └── server.options.go
    └── lib
        └── lib.go
  1. 这在惯用语上正确吗?我知道那里没有很多共识,但我想遵循最佳实践。
  2. 当我运行时,go build我得到'意外的模块路径“github.com/ragurney/app_name/cmd/app_name”',但是当我运行go build ./...它时它可以工作。为什么?

当我移动main.go到顶层时,一切都按预期工作。我不应该将/cmd模式与模块一起使用吗?

4

2 回答 2

10

要回答您的第一个问题,它完全是固执己见的,无论您最喜欢什么,对于您应该与之一起使用的其他人来说也很容易理解(我认为这很好)。

要回答您的第二个问题,原因go build ./...go build从根目录相反是因为./...从当前目录(根目录)开始并搜索所有程序入口点并构建它们。当您main.go使用这些新信息移动到根目录时,go build工作就有意义了,因为它只在当前目录中查找。

您可以明确地说go build ./cmd/app_name哪个也可以。

您的应用程序结构与模块完美配合,因为我使用了与它非常相似的东西(https://www.ardanlabs.com/blog/2017/02/package-orientation-design.html),并且模块对我来说效果很好。

于 2018-11-02T16:59:30.660 回答
0

据我所知,您的项目结构没有任何问题。对我有用的是从项目根目录运行 go build/run 命令

例如。 go run github.com/username/project/cmd/somecommand

go build -o somebinary github.com/username/project/cmd/somecommand

于 2018-11-02T16:59:37.967 回答