Open hausdorff opened 7 years ago
Wading into this a little deeper, when we delete all lines calling the stringer (i.e., // +gen stringer
, as we do in this line), the problem disappears. How interesting! :)
Ok, quick perusal of clipperhouse/stringer
and I found the place we're calling types.Config
, but without setting the importer to imports.Default()
.
I have absolutely no idea what I'm doing, but based on the error message in the Go type
package's source, it looks to me like the correct thing to do is just add this here.
Thus, I've created a PR. I'm not sure how close to the solution this really is, but I think this should get you a good way towards fixing the problem if it doesn't.
Just a follow up: is there any interest in collaborating to fix this? I'd really like to use this stuff, and am happy to help in my spare time.
Same problem here, same solution: remove stringer
generator.
Is there a better way of generating generic containers today? This repository seems a bit outdated. Is there any maintained fork somewhere? The work here is awesome and really useful, outstanding. Would be great to hear that all this work is not going to be lost when the latests versions of go only support modules, etc.
Thanks in advance!!!
Is any fix available?
@hausdorff In my attempt to solve issue by adding imports.Default()
didn't lead me to success. Do you?
@robermorales Also when I commented the line with importing stringer module I still view the error: could not import fmt (can't find import: "fmt")
. Do you solve the issue?
@clipperhouse Any help?
I'm working with a somewhat bitrotted project and Go 1.8, and when I run
gen
in the root directory, I get a mysterious error:This line is a normal
import "fmt"
. The only results that are even close to this refer to the Go type resolver, which leads me to believe the problem is actually typewriter. It's difficult to know for sure, though, because there's not stack trace included.