gocov test ./my doesn't work about gocov HOT 9 OPEN

Yes, you need to use a proper package structure inside $GOPATH. The fact
that go test ./my works is luck, not design.

On Thu, Jan 24, 2013 at 4:27 AM, Alexey Palazhchenko <
[email protected]> wrote:

gocov test ./my doesn't work (at least for a package not in GOPATH), but go
test ./my works.

gocov test ./my
ok _/Users/AlekSi/Code/secret-path/colorizer 0.009s
failed to parse gocov output: stat /var/folders/v2/xzyp4lkn5nl0gpjrs3n66_5w0000gn/T/gocov740203931/gocov.out: no such file or directory

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30.

from gocov.

The fact that go test ./my works is luck, not design.

It is design: http://golang.org/cmd/go/#hdr-Description_of_package_lists

from gocov.

I dunno about axw, but I'm not interested in continuing to support the idea
that $GOPATH is optional.

On Thu, Jan 24, 2013 at 7:08 AM, Alexey Palazhchenko <
[email protected]> wrote:

The fact that go test ./my works is luck, not design.

It is design: http://golang.org/cmd/go/#hdr-Description_of_package_lists

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-12619602.

from gocov.

I occasionally find it useful to build some code outside of a GOPATH when testing some code snippet out. Doing coverage analysis on a non-GOPATH package doesn't seem very useful, though. If it can be done with minimal change to gocov, I'll take a patch; otherwise it will remain a limitation.

from gocov.

@axw I see it the exact opposite way around. Frequently I will want to generate a coverage report on the application I am currently working on. It makes no sense to have the path to all of my applications be on the GOPATH, but I'd like to have the ability to generate a gocov report on the app in the current directory.

This would also be a building block for automatically generating and using coverage reports as part of our continuous integration in Jenkins for example.

from gocov.

@ohookins Fair enough. I suppose my thinking was biased by the fact that my Go programs are predominantly in go-gettable locations, thus end up in GOPATH. Clearly this won't be the case for all.

I'll take a look when I get some spare time.

from gocov.

It makes no sense to have the path to all of my applications be on the GOPATH

That's what I thought. Then I bumped into "unrecognized import path" error (my use-case was quite untypical). I changed all my imports to GOPATH-style and rearranged code. Now my project and all dependencies are stored in one GOPATH. It feels natural just after few minutes, and doesn't produces "interesting" error messages. I suggest you to do the same.

Also, AFAIU, changing gocov to work with relative imports is a not trivial task.

This would also be a building block for automatically generating and using coverage reports as part of our continuous integration in Jenkins for example.

I configured Jenkins to checkout code into $GOPATH/src/github.com/AlekSi/project and run gocov as gocov test github.com/AlekSi/project.

@axw May I propose to reject relative imports with a meaningful error message (probably with link to this issue) until you have a time to figure out how to support them?

from gocov.

@AlekSi Done. If you attempt to gocov test a package or program that doesn't exist in GOPATH, then you'll get a slightly more useful error message. Your workaround to checkout into a dummy GOPATH should continue to work.

I have a vague idea of how this might be made to work in gocov: when a package is encountered that is not in GOPATH, symlink it into the synthesised GOROOT with the name "github.com/axw/gocov/goroot/".

I briefly attempted to get this to work, but my brain is a bit addled at the moment (still acclimatising to newborn baby sleep patterns). Anyone interested in getting this to work is welcome to attempt a fix and send a pull request.

from gocov.

+1 for this feature. Need for Jenkins workspace integration

from gocov.