Trying to do code coverage with go fails: go test -coverprofile=coverage.out go tool: no such tool "cover"; to install: go get code.google.com/p/go.tools/cmd/cover It seems the issue is that it's in a separate code base: https://code.google.com/p/go.tools/ as opposed to: https://code.google.com/p/go/ the upstream source tarball (for 1.2) does not contain these tools either. There's an upstream bug for this: https://code.google.com/p/go/issues/detail?id=6927 the ebuild could install those tools for the user, as a workaround until upstream gets their (packaging) act together. As a workaround: # GOPATH=/tmp/ go get code.google.com/p/go.tools/cmd/cover Reproducible: Always Steps to Reproduce: go test -coverprofile=coverage.out build1 ~ # eix dev-lang/go [I] dev-lang/go Available versions: 1.1.2 1.2{tbz2} **9999 {bash-completion emacs vim-syntax zsh-completion} Installed versions: 1.2{tbz2}(12:52:25 AM 02/06/2014)(bash-completion vim-syntax -emacs -zsh-completion) Homepage: http://www.golang.org Description: A concurrent garbage collected and typesafe programming language
Here is where upstream talks about the test coverage tool [1]. I'm not exactly comfortable with installing it automatically with the dev-lang/go ebuild, because I think "go get" in that context is installing from a live repository, and if I do that, we can't have a stable dev-lang/go. Thoughts? [1] http://golang.org/doc/go1.2
(In reply to William Hubbs from comment #1) > Here is where upstream talks about the test coverage tool [1]. > I'm not exactly comfortable with installing it automatically with the > dev-lang/go ebuild, because I think "go get" in that context is > installing from a live repository, and if I do that, we can't have a > stable dev-lang/go. > > Thoughts? > > [1] http://golang.org/doc/go1.2 You could use a known revision from git.
(In reply to austinenglish@gmail.com from comment #2) > (In reply to William Hubbs from comment #1) > > Here is where upstream talks about the test coverage tool [1]. > > I'm not exactly comfortable with installing it automatically with the > > dev-lang/go ebuild, because I think "go get" in that context is > > installing from a live repository, and if I do that, we can't have a > > stable dev-lang/go. > > > > Thoughts? > > > > [1] http://golang.org/doc/go1.2 > > You could use a known revision from git. Err, mecurial..or whatever the hot VCS of the day is :)
(In reply to austinenglish@gmail.com from comment #3) > (In reply to austinenglish@gmail.com from comment #2) > > You could use a known revision from git. > > Err, mecurial..or whatever the hot VCS of the day is :) Not directly. Go get doesn't let you do that, and Gentoo policy would require me to make a tarball snapshot and mirror it. Also I wouldn't do this in the dev-lang/go package, it would be dev-lang/go-tools.
(In reply to William Hubbs from comment #4) > (In reply to austinenglish@gmail.com from comment #3) > > (In reply to austinenglish@gmail.com from comment #2) > > > You could use a known revision from git. > > > > Err, mecurial..or whatever the hot VCS of the day is :) > > Not directly. Go get doesn't let you do that, and Gentoo policy would > require me to make a tarball snapshot and mirror it. Well, yeah, of course that won't work for go get. That's outside of portage's control, though, so I don't see why it matters. > Also I wouldn't do this in the dev-lang/go package, it would be > dev-lang/go-tools. Works for me, ideally dev-lang/go would rdepend on dev-lang/go-tools, but as long as I can get it from portage I'm happy.
I was looking for godoc. Seems to be an essential tool because Go keeps telling you to use it (go help fmt -> For more about gofmt, see 'godoc gofmt'.). Unfortunately that's not part of the ebuild either so you have to http://golang.org/doc/install/source#tools # go get code.google.com/p/go.tools/cmd/... It would be nice if this could be incorporated in an ebuild somehow.
Looking at the upstream bug, it looks like it will be better to wait for them to fix this then encorporate their patch.
Tweaking subject based on the assumption I'm not the only one specifically looking for "godoc". As described in https://code.google.com/p/go/issues/detail?id=6654: - the "godoc" tool (and other tools) cannot easily be installed as user: "go get code.google.com/p/go.tools/cmd/godoc" tries to install them into /usr/lib/go/, not the user's GOPATH. The "workaround" provided in this bug needs to be run as root, and writes into /usr/. It is therefore not a workaround I am willing to run. - "it is NOT a goal to allow updating godoc or vet or cover or any other tool separately from the rest of the tree", so having these installed along with go itself makes more sense than having the user "go get" them from vcs. If there is a workaround to install the tools without root privs, please share (preferably in the go ebuild, at least on this bug).
On my opinion the go ebuild should include the go tools. The popular opinion in #go-nuts was that a proper go distribution includes the tools. Debian bundles them, too, and people seem to be happy. There seems no sane way to install the tools as a user other than setting the whole toolchain up oneself.
Please package the tools (either in the go ebuild or a separate ebuild). The linked issue was moved to https://github.com/golang/go/issues/6654 and closed. Upstream considers this working as intended. Looking at upstream's misc/makerelease/makerelease.go, they bundle the latest revision on the release-branch.go1.4 branch of https://github.com/golang/tools/ with their binary releases. Ideally we'd convince upstream to start using tags in and/or source tarballs of that repository (corresponding to Go releases). You could then write ebuilds or include the tools in the dev-lang/go ebuild. I agree upstream's release process is broken when it comes to the tools, but please consider working around it to provide feature parity between upstream's binary releases and what can be installed through ebuilds (or convince upstream to improve their release process: it's not ideal it's not obvious which sources go into their binary releases).
I've added the following packages: dev-go/go-crypto dev-go/go-text dev-go/go-net dev-go/go-oauth2 dev-go/go-sys dev-go/go-tools (installs godoc)
Thanks! godoc works great. I'm not closing this in case there are other tools missing I don't know about.
In Go 1.5, cover and vet are now part of the main go repository. I am closing this bug; please open a new one if you are missing a specific tool. Thanks, William
