Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
purpleidea opened this issue May 5, 2019 · 5 comments

Comments

@purpleidea
Copy link

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
Copy link
Author

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

purpleidea added a commit to purpleidea/mgmt that referenced this issue May 5, 2019
Here's a fix for another golang regression in 1.11.x which wasn't needed
before! More info in: golang/go#31843
purpleidea added a commit to purpleidea/mgmt that referenced this issue May 5, 2019
Here's a fix for another golang regression in 1.11.x which wasn't needed
before! More info in: golang/go#31843
@josharian
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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 andybons changed the title stringer regression with stringer: error: 0 packages found x/tools/cmd/stringer: regression with stringer: error: 0 packages found when GOCACHE=off May 13, 2019
@gopherbot gopherbot added this to the Unreleased milestone May 13, 2019
@andybons
Copy link
Member

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.

@golang golang locked and limited conversation to collaborators May 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants