Aws-sam-cli: SAM Build support for Go with dep

[jfuss]

Describe your idea/feature/enhancement

sam build should support the Go runtime.

Proposal

https://github.com/awslabs/aws-lambda-builders/pull/54

[volkangurel]

I'd go a step further and say it should support go builds with Go Modules

[jfuss]

I should have been more explicit. This is tracking what is already out for review which is support for dep. If you are looking for support outside of dep, open an issue first in https://github.com/awslabs/aws-lambda-builders so we can understand details and track the additions there first.

[volkangurel]

Sounds good!

[tj]

even just adding a GOOS=linux GOARCH=amd64 go build ... should be sufficient I think, dep is being replaced by mods. In either case the go build should be enough, and then it supports both :D.

If people use non-standard package management I think that's more up to the user to ensure they've run dep ensure etc, but in general Go doesn't care where the deps are from.

[jfuss]

@tj @volkangurel Added a PR for Go Module support in aws-lambda-builders. @volkangurel, @sthulb, and I had a converstation on slack (in the lambda-builders-dev channel) about making the default be Go Modules but allowing customers to use Dep as well. We are still figuring out how to allow support for this exactly, though (many workflows for a given runtime).

If people use non-standard package management I think that's more up to the user to ensure they've run dep ensure etc, but in general Go doesn't care where the deps are from.

That is an interesting point. I think that strengths the reason for using Go Mod as the default. The one hurdle is that build forces a customer to have the manifest file. So customers doing this method you need both manifest files. From a customers point of view, it is clunky but does give a way to do it.

[tj]

I'm not sure any special-casing is needed, by default go build will grab the modules in go.mod if they aren't present locally, and then for dep and friends you typically have everything installed locally while you're working anyway, but that might not play too well with the use of Docker, I forgot about that

[jfuss]

Dep and Mod have different manifest files. The Go Mod workflow would expect a go.mod file. So customers this workflow but use dep would need both Gopkg.toml and go.mod when using sam build.

We will support both as it is a dependency manager people use.

[sthulb]

@tj I don’t disagree. Go mod is the future of go based building for sure.

We have dep to cover our bases. Much like we still support py2

[sriram-mv]

Closing this, since support for Go Mod has landed. Feel free to re-open if there is an explicit need for this, and will mark it as a feature request.