英文:
Go Lang Workspace Duplicate Package Name Executable Collision
问题
如果按照GoLang文档中的工作区结构，可能会出现两个可执行包共享相同包名的情况。
例如，有两个来自github的包：
$ $GOPATH/src/github.com/alpha/import
$ $GOPATH/src/github.com/beta/import
首先安装用户alpha的import包：
$ go install github.com/alpha/import
二进制可执行文件现在可以在$GOPATH/bin中找到，并且命名为import。
然后安装用户beta的第二个包：
$ go install github.com/beta/import
这个安装/构建操作将用用户beta的import二进制文件替换用户alpha的import二进制文件。
更好的命名约定可以避免这种冲突；然而，在使用第三方库时，是否有解决此问题的标准做法？
英文:
If following the GoLang documentation for workspace structure it is possible that two executable packages will share the same package name.
For example, there are two packages from github:
$ $GOPATH/src/github.com/alpha/import
$ $GOPATH/src/github.com/beta/import
The import package from user alpha is first installed:
$ go install github.com/alpha/import
The binary executable is now available in $GOPATH/bin and is named import.
Then the second package from user beta is installed:
$ go install github.com/beta/import
This install/build will replace the existing import binary from user alpha with the import binary from user beta.
A better naming convention could avoid this collision; however, is there a standard practice for fixing this issue when using third party libraries?
答案1
得分: 3
这种冲突只会发生在可执行文件上，而绝对不会发生在软件包上。可执行文件较为罕见，并且通常具有独特的名称，因此在实践中我从未遇到过这个问题。
解决方法或最佳实践非常明显和简单：只需在安装后重新命名二进制文件即可。
英文:
This collision happens only for executables and never for packages. Executables are much less common and often have distinguishing names so in practice I never encountered this problem.
The "fix" or "best practice" is obvious and dead simple: Just rename the binary after installing.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论