-1

I have a npm binary I'd like to package up in a Docker container. I have this configuration:

# Docker image for the Mongo Stitch command

FROM golang:alpine

# Do a system update
RUN apk update

RUN apk add git

# Declare base dir
WORKDIR /root

# The console binary for Mongo Stitch
RUN git clone https://github.com/10gen/stitch-cli.git

WORKDIR /root/stitch-cli

RUN go build

CMD ["/bin/sh"]

I get this error:

main.go:8:2: cannot find package "github.com/10gen/stitch-cli/commands" in any of:
    /usr/local/go/src/github.com/10gen/stitch-cli/commands (from $GOROOT)
    /go/src/github.com/10gen/stitch-cli/commands (from $GOPATH)
main.go:9:2: cannot find package "github.com/10gen/stitch-cli/utils" in any of:
    /usr/local/go/src/github.com/10gen/stitch-cli/utils (from $GOROOT)
    /go/src/github.com/10gen/stitch-cli/utils (from $GOPATH)
main.go:11:2: cannot find package "github.com/mitchellh/cli" in any of:
    /usr/local/go/src/github.com/mitchellh/cli (from $GOROOT)
    /go/src/github.com/mitchellh/cli (from $GOPATH)

This is unexpected, since I imagine the official Go container would have everything I need. I have these vars set:

~ # set | grep GO
GOLANG_VERSION='1.11.5'
GOPATH='/go'

The build instructions say that go build is sufficient to get this working. I have played with go get, with various error outputs, but I think this might be a wild goose chase, since if I had to fetch dependencies manually the instructions would have said so.

For what it's worth though, if I do issue a go get in the container shell, I get this:

~/stitch-cli # go get
go get: no install location for directory /root/stitch-cli outside GOPATH
    For more details see: 'go help gopath'

I've tried parsing the material in said help file, but I am not sure what part applies to my case.

So, I wondered if missing GOROOT was worth fixing. I did this:

~/stitch-cli # which go
/usr/local/go/bin/go
~/stitch-cli # GOROOT=/usr/local/go
~/stitch-cli # export GOROOT
~/stitch-cli # go build
# _/root/stitch-cli
./main.go:25:3: cannot use commands.NewWhoamiCommandFactory(ui) (type "github.com/10gen/stitch-cli/vendor/github.com/mitchellh/cli".CommandFactory) as type "github.com/mitchellh/cli".CommandFactory in map value
./main.go:26:3: cannot use commands.NewLoginCommandFactory(ui) (type "github.com/10gen/stitch-cli/vendor/github.com/mitchellh/cli".CommandFactory) as type "github.com/mitchellh/cli".CommandFactory in map value
./main.go:27:3: cannot use commands.NewLogoutCommandFactory(ui) (type "github.com/10gen/stitch-cli/vendor/github.com/mitchellh/cli".CommandFactory) as type "github.com/mitchellh/cli".CommandFactory in map value
./main.go:28:3: cannot use commands.NewExportCommandFactory(ui) (type "github.com/10gen/stitch-cli/vendor/github.com/mitchellh/cli".CommandFactory) as type "github.com/mitchellh/cli".CommandFactory in map value
./main.go:29:3: cannot use commands.NewImportCommandFactory(ui) (type "github.com/10gen/stitch-cli/vendor/github.com/mitchellh/cli".CommandFactory) as type "github.com/mitchellh/cli".CommandFactory in map value
~/stitch-cli # 

OK, maybe this is a bit further, but I am now firmly in "trying random things" territory. Is there something I can do to have it work out of the box?

I also tried ordinary Alpine (v3.9) with Go manually installed, and that did not even have GOPATH set, but I got much the same "cannot find package" errors. What could I try next to get this to compile?

I have also tried switching to the full-fat version of the Golang image, rather than this lighter Alpine image, and I get the same issues, both with build and get.

I could also go back to installing via NPM, but I had problems with that (and that issue would probably be out of scope of a Golang question).

Possible duplicate

My question has been identified as a possible duplicate of this question. I think that question is essentially a duplicate of the secondary problem noted here, which as I mentioned earlier, was probably a red herring. If there are any dups detailing an answer to the first error, that would likely be a better signpost.

halfer
  • 19,824
  • 17
  • 99
  • 186
  • Possible duplicate of [package's type cannot be used as the vendored package's type](https://stackoverflow.com/questions/38091816/packages-type-cannot-be-used-as-the-vendored-packages-type) – Jonathan Hall Feb 03 '19 at 16:38
  • Thanks @Flimzy, I will look at those answers. I would be reluctant to move any deps, as I think this ought to work out of the box. But removing `vendor` and re-fetching seems okay. I will try that... – halfer Feb 03 '19 at 16:40
  • One of those answers recommends the `godep` command, which I do not have. Furthermore, it is deprecated and archived on GitHub. I have loade `dep` instead, and am trying to load dependencies with this. – halfer Feb 03 '19 at 16:52
  • @Flimzy: thanks, your pointer helped. Now that I have an answer (below), would you say a better dup is available? I sense the real error was in the first block, but yours relates to the second. Alternatively, if you would like to post an explanatory answer, I'll accept yours in preference to my own. – halfer Feb 03 '19 at 18:30

1 Answers1

1

Flimzy kindly pointed me to another answer (which I would never have found without knowledgeable assistance). Since I think the build process is non-trivial, especially for non-Gophers such as myself, I will post the new Dockerfile:

# Docker image for the Mongo Stitch command

FROM golang:alpine

# Do a system update
RUN apk update

RUN apk add git curl

# Declare base dir
WORKDIR /root/src

RUN git clone https://github.com/10gen/stitch-cli.git

WORKDIR /root/src/stitch-cli

# Remove the old dependencies
RUN rm -rf vendor

# Fetch the dependencies
RUN curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
RUN GOPATH=$GOPATH:/root dep ensure

# Now it should build
RUN GOPATH=$GOPATH:/root go build

CMD ["/bin/sh"]

The fetching of the dependencies results in this error:

Warning: the following project(s) have [[constraint]] stanzas in Gopkg.toml:

  ✗  github.com/10gen/escaper
  ✗  github.com/dgrijalva/jwt-go
  ✗  github.com/ogier/pflag
  ✗  gopkg.in/mgo.v2

However, these projects are not direct dependencies of the current project:
they are not imported in any .go files, nor are they in the 'required' list in
Gopkg.toml. Dep only applies [[constraint]] rules to direct dependencies, so
these rules will have no effect.

Either import/require packages from these projects so that they become direct
dependencies, or convert each [[constraint]] to an [[override]] to enforce rules
on these projects, if they happen to be transitive dependencies.

However, it still seems to compile. My worry is that I have had to do far more steps than are in the documentation, which leads me to think that I have made this more complicated than it needs to be.

Docker repo

I have made my Docker repo permanently available here.

halfer
  • 19,824
  • 17
  • 99
  • 186
  • I would like to point out that GOPATH is already set by `golang:alpine`. If you have a [look at the Dockerfile](https://github.com/docker-library/golang/blob/2e795f515357c575359f0720acaf7f5490f8bcf5/1.11/alpine3.8/Dockerfile#L59), it is set to `/go`. Furthermore, I‘d strongly suggest using a [multi stage build](https://docs.docker.com/develop/develop-images/multistage-build/). Edit: which you already did in the repo, but not your answer here... ;) – Markus W Mahlberg Feb 04 '19 at 09:49
  • Thanks @MarkusWMahlberg. Yes, I got a multi-stage build, but only once the build worked - that's just icing on the cake really. You are right that `GOPATH` was set, but GoLang insisted that my source project needed to be in `{$GOPATH}/src`, hence the env var hackery. – halfer Feb 04 '19 at 12:42
  • If this can be simplified (maybe because blatting the vendor folder is not actually necessary?) I am all ears `:=)` – halfer Feb 04 '19 at 12:42