x/tools/cmd/stringer: regression with stringer: error: 0 packages found when GOCACHE=off

[purpleidea]

What version of Go are you using (go version)?

$ go version
go version go1.11.7 linux/amd64

What operating system and processor architecture are you using (go env)?

GNU+Linux F29

In my project we run go generate in a package directory, and the package contains a file with the go:generate line that calls stringer with:

//go:generate stringer -type=Kind -output=kind_stringer.go

This always worked in golang 1.10.x Now it fails with:

stringer: error: 0 packages found

My code lives in $GOPATH/src/....
But because that is a stupidly difficult place to get to, I have a symlink in: ~/code/foo/ that points to that dir. If I do a cd $(pwd -P) to get rid of the symlink then it works, however if I do cd $(pwd -P) && go generate then it fails.

1. It's terrible that there's yet another behaviour regression. Why doesn't the go compatibility promise apply?
2. For some reason you can't seem to even work around this with a pwd -P trick. What gives?

Alternate failures include trying cd $(pwd -P) && bash -c 'go generate' but it also fails.

Please let us know and add some tests to stop breaking behaviour please!

[purpleidea]

Update: after some intense debugging, it seems the regression is related to GOCACHE. If it's set to off then this breaks. Previously it didn't matter. It needs to be set to workaround this other regression:

#29378

[josharian]

A few quick comments:

• The Go 1 compatibility promise does not apply to tools. But I’m sorry the experience has been frustrating.

• symlinks have long been semi-functional at best. I don’t expect that to change.

• Using Go modules should let you put your code in a more convenient place for you, hopefully obviating the need for symlinks.

• You may want to double-check that you have an up-to-date stringer (plus its dependencies). It has been changing a fair amount recently as part of the shift to modules.

[purpleidea]

My feedback is inline in the hopes it will benefit the project. I'm not a big golang user like kubernetes or docker, but I don't think I'm a slouch =D HTH

The Go 1 compatibility promise does not apply to tools. But I’m sorry the experience has been frustrating.

I understand. My experience with golang tooling has been negative. You might care to consider whether the changes upstream makes have been worth the cost.

symlinks have long been semi-functional at best. I don’t expect that to change.

Pity, they're valuable things :) Loose support for these, and you'll loose the Linux community.

Using Go modules should let you put your code in a more convenient place for you, hopefully obviating the need for symlinks.

I will not be using go modules unless they allow me to remain on git master for all my dependencies and don't require a new metadata file. My understanding is that neither of these are possible. The only time I want to track a specific version of a dependency, I do so with git submodules. This works perfectly with the vendor/ dir. Git is exactly excellent at doing it's job here, and adding this inelegant tool into the mix hurts the picture. If I've misunderstood go modules, please LMK.

You may want to double-check that you have an up-to-date stringer (plus its dependencies). It has been changing a fair amount recently as part of the shift to modules.

I'm using the distro version. The fact that something as basic as stringer experiences breaking changes so late into the golang lifecycle is a warning for me.

Cheers!

[ianlancetaylor]

Setting GOCACHE=off is no longer supported as of Go 1.12, as documented at https://golang.org/doc/go1.12#gocache . If your problem only arises with GOCACHE=off, then it is unlikely to be fixed.

Sorry for the trouble you are having.

[andybons]

Thanks for your feedback. Sorry it’s been a frustrating experience for you.

Since GOCACHE=off is no longer supported it looks like there’s not much we can do, here. Closing.