英文:
Is it common practice to symbolic link to the GOPATH folder?
问题
我的git项目存储在这里:
~/dev/git/project1 ...
我正在开始一个golang项目,由于它需要使用GOPATH,所以在我的项目git路径和GOPATH之间创建一个符号链接是常见的做法吗?
英文:
My git projects are stored here:
~/dev/git/project1 ...
I am starting a golang project, and since it requires using the GOPATH is it common practise to create a symbolic link from my projects git path to GOPATH?
答案1
得分: 3
由于软件包之间的依赖问题,使用符号链接来处理GOPATH。然而,GOPATH的结构始终暗示它应该用于多个项目,并且Go开发人员不鼓励使用符号链接的GOPATH。
然而,在最新版本(1.6)中,他们最终解决了依赖问题(在1.5中试验性地引入),通过在包的顶层放置一个名为vendor/
的文件夹的形式来实现(链接)。在导入语句中使用的包将在常规的GOPATH之前搜索此文件夹。
有各种工具可用于简化依赖过程,如godep或glide,使用vendor/
文件夹比符号链接的GOPATH要节省时间。使用供应商包还比符号链接的依赖项更可重现,确保您的包适用于所有人。
因此,我鼓励您不要使用符号链接的GOPATH,而是使用这个新引入的标准。
英文:
Because of dependency issues between packages, symlinking was used for the GOPATH. The structure of GOPATH, however, always suggested that it was to be used for multiple projects and symlinking your GOPATH
has been discouraged by the go developers.
In the latest version (1.6), however, they finalised a solution to the dependency problem (experimentally introduced in 1.5), in the form of a folder named vendor/
placed at top level of your package (link). This folder will be searched before the regular GOPATH
for package used by import statement.
There are various tools to use to streamline the dependency process like godep or glide, making using the vendor/
folder a lot less time-consuming than symlinking the GOPATH
. Using a vendor package is also better reproducible than symlinked dependencies, ensuring your package will work for everyone.
So I would encourage you not to symlink your GOPATH, and use this newly introduced standard.
答案2
得分: 1
我最终做的是在我想要保持独立于正常全局$GOPATH
的Go项目中创建了自己的GOPATH
。
我在项目的根目录下创建了一个名为b
的脚本,它执行以下操作:
- 检查
src
是否存在(在项目文件夹中,例如~/dev/git/project1
):如果不存在,则创建它; - 检查
src/mypackage
是否存在:如果不存在,则创建符号链接src/mypackage -> ~/dev/git/project1
; - 使用别名调用:
alias b='. ./b'
这样,相同的b
(简称为“build”)进入~/dev/git/project1/src/mypackage
,然后执行go install
。
如果你有一个main
包,它将在~/dev/git/project1/bin
中创建一个可执行文件。
这样,我的每个Go项目都保持独立,不会迷失在我正常的$GOPATH/src
中的其他Go包中。我将全局的$GOPATH
保留给帮助我开发Go的全局项目,例如golang.org/x/tools/cmd/...
、github.com/fzipp/gocyclo
和其他类似的工具(代码检查工具)。
换句话说,我不会创建GOPATH
的符号链接。
我会将我的项目中的包创建为本地GOPATH
的符号链接(特定于该项目),但是GOPATH
本身是一个固定的文件夹(同样是特定于我的项目),像往常一样定义,没有任何符号链接。
这与用于供应源代码依赖项的vendor文件夹完全兼容。
以下是示例脚本:
alias b='. ./b'
cd /path/to/my/project
b:
#!/bin/sh
if [ ! -e src ]; then mkdir src ; fi
if [ ! -e src/myproject ]; then ln -s /path/to/my/project src/myproject; fi
cd src/myproject
go install
cd ../..
英文:
What I end up doing is instead created my own GOPATH
within a go project I want to keep isolated to my normal global $GOPATH
.
I make a 'b
' script (at the root folder of the project) which:
- check if
src
exists (in the project folder, here in~/dev/git/project1
): if not it creates it; - check if src/mypackage exists: if not, if creates the symbolic link
src/mypackage -> ~/dev/git/project1
. - is called with an alias:
alias b='. ./b'
That way, the same 'b
' (short for 'build') goes into ~/dev/git/project1/src/mypackage
, and does a go install
.
If you have a main
package, that will create a binary in ~/dev/git/project1/bin
.
That way, each of my go project remains autonomous, not lost in a sea of other go packages in my normal $GOPATH/src
. I reserve the global $GOPATH
for global projects that helps me to develop in go: golang.org/x/tools/cmd/...
, github.com/fzipp/gocyclo
and the likes (other linters).
In other words, I do not symlink GOPATH
.
I do symlink my package inside my project to a local GOPATH
(local to said project), but the GOPATH itself is a fixed folder (again specific to my project), defined as usual, without any symlink)
And that is perfectly compatible with the vendor folder for vendoring source dependencies.
alias b='. ./b'
cd /path/to/my/project
b:
#!/bin/sh
if [ ! -e src ]; then mkdir src ; fi
if [ ! -e src/myproject ]; then ln -s /path/to/my/project src/myproject; fi
cd src/myproject
go install
cd ../..
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论