Add golint to golang image

[yongtang]

We use golang through docker extensively, e.g.,

docker run -i -t --rm -v $PWD:/go/src/... -w /go/src/... golang go build

Typically before compiling our source code with golang, we will invoke golint. Currently the golint is not available in golang images so we have to download golint:

go get -u github.com/golang/lint/golint 

it would be nice if golang docker image comes with golint installed already.

[tianon]

I'm personally very strongly -1 on including this by default -- it's trivial for users to add after the fact with a simple two-line Dockerfile (FROM golang:version, RUN go get github.com/golang/lint/golint), and it's not necessary for most use-cases of this image.

Combine that with automated builds (https://docs.docker.com/docker-hub/builds/) and repository links (https://docs.docker.com/docker-hub/builds/#repository-links) and it's reasonably easy to have an up-to-date image built FROM this one with golint pre-installed.

To elaborate a little bit more, if we add golint, what's going to be next? godeps? Where do we draw the line?

[ybubnov]

I understand, that point is to keep only the compiler binary within these images, but if we take a look at the projects written in Go, it could become obvious, that compiler itself is not enough to fulfill the regular build requirements. The build divided into the several steps, that include the code style verification and static checking (which is a golint field). And just for a note, golint is not an exotic tool, instead it is an officially maintaining tool by golang community.

It's clear that from the perspective of the developer, the creation of such tiny image is the brainless task, but if, say, look it from the side of convenience of use - not to create the image at all is way more beneficial (as simply it reduces the need of additional image build step).

Talking about the godeps - at this moment there is no defacto standard of the package manager in golang world, this is why it is very straightforward decision on making it part of the golang image. But when it will become, I will be arguing on making it part of this image again.

The reason is simple - the language is an infrastructure, not a compiler (or interpreter), therefore the programs, that are larger in size of "hello world" on my opinion require these verification steps, and so tools to make it.

It could be also compared with ruby image, which ships the gem package manager, or python image with pip package manager - I don't see the reason why golang image should be special from this point of view.

[tianon]

I think the "golint" parallel for Python would be "tox", wouldn't it?

[ybubnov]

I think that pylint is more relevant in this context.

[client9]

strong -1

I appreciate the intent, but I'd prefer this container to mirror what is in the official downloads. Just like with them, you need to install golint if you want it. Same with goimports, stringer and many of the other golang tools in https://godoc.org/golang.org/x/tools

I'm a big fan of style checkers and static analysis on source code. But it's unlikely just adding golint is enough for a complete static analysis/code formatting build step, especially given the number of tools now (e.g. https://github.com/alecthomas/gometalinter) so you'll be making your own container OR wrapping up golint in it's own CLI container anyways (https://spin.atomicobject.com/2015/11/30/command-line-tools-docker/ ).

Most importantly golint doesn't have a release schedule nor is it part of golang proper (intentionally). In addition it's not stand-alone, and links into golang.org/x/tools/go/gcimporter15, so that needs versioning too. Basically it's a third-party utility, even if it's maintained by google/golang team. How should this container be updated and versioned with golint changes? For the current go version? for older go versions? There are pros and cons here, but they are decisions I'd like end-users to make and not @tianon who probably has enough work already.

For these reasons (and others), I'd prefer to keep this container simple and mirror what is in the official downloads.

regards,

nickg

[ybubnov]

I see. In conclusion, such tools better to keep in the custom images. So I'm closing the associated pull request.

[steve-gray]

I think potentially an avenue of discussion that wasn't raised was the prospect of doing what NodeJS does, having a 'slim' version thats just the minimum and a full-fat version that's got the tools you need for native bindings (GCC, make, plus some really common global libraries). That would seem to be the best of both worlds.

[lyda]

Sigh. As someone who lives behind a slow net connection, I find this decision depressing. Disk is cheap, bandwidth is not. Docker caches images quite well. I hope this gets revisited.