英文:
Implications of not using repo path for my own packages
问题
假设我决定按照以下方式组织所有个人开发的包：
$GOPATH/
bin/
pkg/
src/
somepkg1
somepkg2
...
somepkgN
此外，假设它们之间存在大量代码重用，因此我决定将整个$GOPATH工作区放在同一个Git存储库下（每个包可以是一个子模块），而不是更传统的情况，其中子包不太一致（仅因为使用go get来自同一工作区）：
$GOPATH/
bin/
pkg/
src/github.com/<me>/
somepkg1
somepkg2
...
somepkgN
我可以看到，对于前一种方法（在包路径中不使用github.com/<me>/），go get将无法获取包，因为它们没有“声明”自己可在网上获得。然而，可以通过使用git子模块轻松解决这个问题，这样所有的包都会被首先获取（请注意，这是一个严格受控的生态系统，不会出现名称冲突）。
除了go get之外，不使用完整路径来引用包还有其他限制吗？
（我主要关注的是某些代码重构/分析工具的限制，这些工具利用了将存储库路径作为基本路径的约定，允许go get在网上查找包。）
英文:
Suppose I decide to keep all personally developed packages organized
as follows:
$GOPATH/
bin/
pkg/
src/
somepkg1
somepkg2
...
somepkgN
Further, suppose there is a great deal of code reuse among them, so I
decide to keep the whole $GOPATH workspace under the same Git
repository (each package could be a submodule), as opposed to more
traditional scenario where subpackages are less coherent (co-existing
solely because of using go get from the same workspace):
$GOPATH/
bin/
pkg/
src/github.com/<me>/
somepkg1
somepkg2
...
somepkgN
I can see that with the former approach (not using github.com/<me>/
in the package paths), go get would not be able to fetch packages as
they are not "declaring" themselves to be available online. However,
one can easily work around that by using git submodules, so all
packages would be fetched in the first place (note it's a tightly
controlled ecosystem so there will be no name clashes).
Is there any other limitation (besides go get) of not using full
paths for packages?
(I am mostly concerned about limitations arising from certain code
refactoring/analysis tools that exploit the repository path as base path convention that
allows go get to look for the package online.)
答案1
得分: 2
对于Go编译器和除了go get之外的所有go工具的所有元素，包导入路径是一个几乎不透明的字符串，其中包含导入路径。您可以按照自己的方式布置代码（编译器本身可以将来自不同文件夹的文件编译为一个包）。如果您不需要或不希望您的代码可以通过go get获取，那么就没有必要使用存储库路径。golang.org/x/tools中的分析和重构工具使用不透明的导入路径（据我所知），并且不访问网络。
英文:
For the Go compiler and all elements of the go tool except go get the package import path is an almost opaque string containing the import path. You can lay out your code like you want (the compiler itself happy compiles files from different folders into one package). If you don't need or want your code to be go getable there is no need to use a repo path. The analysis and refactoring tools in golang.org/x/tools work on the opaque import paths (as far as I know) and do not access the network.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论