假设GOPATH=c:\DATA\go
,然后假设这个:
C:\
DATA\
go\
bin\
pkg\
src\
我的理解是,bin
是作为已编译“命令”的文档用语,我认为它们表示已编译的命令行应用程序。
[pkg
用于已安装的软件包,每个软件包都位于其父OS + architecture文件夹下。
src
是我的代码,每个“项目”都在一个子文件夹下。我不确定我的“项目”文件夹在技术上是否称为“回购”,“模块”或“包”?还是其中任何一个,取决于它是什么?
我的问题:如果我编写自己的模块或软件包,即reusable软件包,那么我应该将其保留在src
或pkg
下吗?
基本的Go语言需要不到几个小时的阅读时间,可惜文件夹惯例给我带来了数天的头抓和工具错误。
这是我们几年来一直在做的事情(看起来工作得很好):
有一个父目录(将其命名为src
或其他名称)。该目录包含项目列表。每个项目都是其自己的模块(即具有自己的go.mod
文件)。
因为有时您需要在项目之间共享代码,所以我们最终得到了一个名为shared
的项目,该项目具有其自己的模块,供其他项目使用。坦白地说,发生了几次,很难确定模块属于project_X
还是shared
。因此,您可能需要注意这一点。
EDIT:忘了提及cmd
表示项目内的主要应用程序,pkg
表示将由外部应用程序使用的库代码。
这种结构的示例树如下:
src
├── project_1
│ ├── cmd
│ ├── go.mod
│ ├── go.sum
│ └── pkg
├── project_2
│ ├── cmd
│ ├── go.mod
│ ├── go.sum
│ └── pkg
├── shared
│ ├── README.md
│ ├── cmd
│ ├── go.mod
│ ├── go.sum
│ └── pkg
| ├── pkg_1
| │ ├── README.md
| │ ├── fi1e_1.go
| │ └── fi1e_2.go
| ├── pkg_2
| │ ├── README.md
| │ └── fi1e_1.go
| ├── pkg_3
| │ ├── pkg_3_1
| | | ├── file_1.go
| | | └── file_2.go
| │ ├── pkg_3_2
| │ └── pkg_3_3
| └── util
| ├── README.md
| ├── common.go
| └── logger.go
└── tools
├── README.md
├── go.mod
├── go.sum
├── tool_1
├── tool_2
└── tool_3