关于外部依赖包

虽然可能与GoogleCloudFunctions关系不大，但我想试试看它的运作方式。

可以继续使用以前的glide或dep进行管理，也可以使用go1.11的Modules。

$ cd helloWorld
$ export GO111MODULE=on
$ go mod init helloWorld

运行此命令后，将在目录中创建一个名为 go.mod 的文件。

关于go mod init

最初尝试执行以下操作时出现了错误。

$ go mod init
go: cannot determine module path for source directory xxxxxxxx(outside GOPATH, no import comments)

我认为只要按照这个问题的Git存储库设置，就不会出现错误。

由于只是想试着运行一下，所以不想创建存储库，因此以下是解决方案。

# 引数としてモジュール名にあたるものを渡してあげる
$ go mod init helloWold

可以查看命令的帮助信息。

go mod init --help
usage: go mod init [module]

试着尝试使用外部依赖包。

我們這次試著依賴於 github.com/go-sql-driver/mysql。原始源碼是使用這個的。

package function

import (
    "fmt"
    "net/http"

    _ "github.com/go-sql-driver/mysql"
)

func HelloWorld(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, World!")
}

如果那样的话，就会下载所依赖的模块。

$ go mod download
go: finding github.com/go-sql-driver/mysql v1.4.1
go: finding google.golang.org/appengine v1.4.0
go: finding github.com/golang/protobuf v1.2.0
go: finding golang.org/x/text v0.3.0
go: finding golang.org/x/net v0.0.0-20180724234803-3673e40ba225

然后在目录中会产生一个名为 go.sum 的新文件，并且更改了 go.mod 的内容。

module helloWorld

require (
    github.com/go-sql-driver/mysql v1.4.1
    google.golang.org/appengine v1.4.0 // indirect
)

进一步，在GOPATH下创建名为mod的目录，将在该目录下管理外部依赖模块。

# gvmでgoを管理しているのでpkg指定
$ ls $GOPATH/pkg
mod

这样就完成了。
可能之前一直使用Go的人已经注意到没有vendor目录。
是的，vendor目录消失了，从管理中解放出来了。

顺便提一下，仅仅执行”go build”得到了相同的结果。

尝试部署

gcloud functions deploy helloWorld --entry-point HelloWorld --runtime go111 --trigger-http

当你部署并查看CloudFunctions控制台时

· function.go → 功能.go
· go.mod → go模块
· go.sum → go依赖总结

当进行部署时。
而且，将测试文件放置进去后也被部署了。

关于供应方

可以使用以前的vendoring技术来达到相同的目的。
执行下面的命令会在目录中创建一个vendor目录，并将其用于构建。

$ go mod vendor

在直接构建时还可以作为选项进行指定。

$ go build -mod vendor

试着部署

gcloud functions deploy helloWorld --entry-point HelloWorld --runtime go111 --trigger-http

最终，vendor目录没有被部署。
如果存在go.mod和go.sum文件，会忽略vendor目录吗？
尝试删除go.mod和go.sum后再进行部署试试。

果然，vendor目录不会被部署。
对于GCF来说，vendor目录似乎不是部署的对象。

如果可能的话，我想知道是否可以通过一些选项或者其他方式来部署。如果您知道，请告诉我一下。

2019年2月12日，我误解了上述内容。

在GCF的GUI中查看源代码选项卡时，未显示vendor目录。但当从实际下载源码并解压后确认时，vendor目录是存在的。

关于先前的vendoring和模块化

这里很有参考价值。

https://github.com/golang/go/wiki/Modules – 此链接指向Golang的官方Wiki页面，介绍了模块系统的相关信息。
https://research.swtch.com/vgo-module – 此链接指向一个关于vgo模块的研究报告，讨论了模块系统的一些特性和用法。
https://www.reddit.com/r/golang/comments/9ai79z/correct_usage_of_go_modules_vendor_still_connects/ – 此链接指向Golang的Reddit论坛，讨论了模块系统中vendor文件夹的正确用法。