gocov
gocov copied to clipboard
axw
gocov test ./my doesn't work
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
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/axw/gocov/issues/30.
The fact that go test ./my works is luck, not design.
It is design: http://golang.org/cmd/go/#hdr-Description_of_package_lists
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/axw/gocov/issues/30#issuecomment-12619602.
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.
@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.
@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.
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?
@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.
