Is the Go plugin going to need any work done to support the new Go modules in Go 1.11?
Yeah I got it working using the go snap rather than the built in plugin. See below.
myapp:
plugin: nil
source: .
build-snaps: [go]
override-build: |
export GOBIN=$SNAPCRAFT_PART_INSTALL/bin
export GO111MODULE=on
export CGO_ENABLED=0
go build
If all you need is that environment, just use bases, as the go snap is the default there, and in the part using the go plugin add
build-environment:
- GO11MODULE: on
Cool, I just tried that and it looks like it would work in cases where your main package uses a name like “github.com/my/app” but it doesn’t work in cases where the the modules use just “app” as the root namespace.
erik@ubuntu ~/C/myapp> snapcraft --debug
Using 'snap/snapcraft.yaml': Project assets will be searched for from the 'snap' directory.
Launching a VM.
Using 'snap/snapcraft.yaml': Project assets will be searched for from the 'snap' directory.
Updating pull step for defaults (source changed)
Pulling myapp
go get -t -d ./project/...
go get: -t flag is a no-op when using modules
go: cannot find main module; see 'go help modules'
Failed to run 'go get -t -d ./project/...' for 'myapp': Exited with code 1.
Verify that the part is using the correct parameters and try again.
snapcraft-myapp # go get -t -d ./project/...
package myapp/cmd: unrecognized import path "myapp/cmd" (import path does not begin with hostname)
...
It’s more than just setting an environment variable. The part source needs to be outside of $GOPATH/src
. This blog post includes a quick rundown of the new build system:
I think the main take-aways are:
-
We can detect Go projects using the new build system by the presence of a
go.mod
in the base source directory. If found, we require Go >= 1.11 to build, and should not try to symlink the source into$GOPATH/src
. We still need$GOPATH
to be set, however. -
The project’s Go package name can be determined by reading the
module
line ingo.mod
. It should not be taken fromgo-importpath
. A warning should be issued ifgo-importpath
is specified in thesnapcraft.yaml
, or if it differs from what is specified ingo.mod
. -
For the pull stage, dependencies should be downloaded using
go mod download
in the source directory rather thango get
. This will ensure versions matching thego.mod
file are downloaded. -
To build packages that are part of the source part, run
go build
in the source directory.
There’s an issue for this in Launchpad: https://bugs.launchpad.net/snapcraft/+bug/1802256
I ran into the same issue as @eberkund too.
Pulling fluxctl
go get -t -d ./github.com/weaveworks/flux/...
go get: -t flag is a no-op when using modules
go: cannot find main module; see 'go help modules'
Failed to run 'go get -t -d ./github.com/weaveworks/flux/...' for 'fluxctl': Exited with code 1.
In my spare time, I started looking at updating the plugin. I didn’t get anything working before GUADEC, but pushed the results up here:
This is completely untested: it might be useful for anyone else who wants to try implementing the feature, but is nowhere near ready for people wanting to build Go snaps.
@jamesh Thanks for starting on this! I saved your modified plugin as a local plugin and it worked for my go modules project. I am unfamiliar with the snapcraft src but I’ll update your fork if I make changes or run into issues.
steps:
-
Fetch the plugin
# from project root mkdir -p snap/plugins wget -O snap/plugins/go_local.py https://raw.githubusercontent.com/jhenstridge/snapcraft/5b94b2ab30e53d3a3339bdba31b29c06a70b4145/snapcraft/plugins/go.py
-
Then modify snapcraft.yaml to use the local plugin:
snapcraft.yaml
... parts: my-project: plugin: go-local
-
Run
snapcraft
as usual.$ snapcraft Launching a VM. Searching for local plugin for go-local ... Ignoring `go-importpath' for the 'kubectl-iexec' part, in favour of go.mod definition