Geert-Johan Riemer

@mgutz yes you would need to import `gopkg.in/godo.v1` instead of direct github path.

Althought this is probably a nice feature for this piece of software to have, I would not recommend running your own version of gopkg.in. The gopkg.in service has a redundant...

I like this idea :+1: One of the first things I thought about was stats as (de-) motivation. When someone publishes their fancy new project and it gets only 10...

Yes github stats only works for projects you own, afaik.

@mcuadros InfluxDB doesn't **need** to be an external service, it would just be preferable to locate it on a different machine so it can't cause any service degradation for gopkg.in....

@niemeyer Right. but what about public stats?

I can see the argument behind "what if I don't want usage stats for my package to be known". What about adding support for a `Gopkg.yaml` that we fetch and...

The new versioning style was introduced in commit https://github.com/niemeyer/gopkg/commit/3334c06823e90ea5648c10971a4c951dac5d722f, but a compatibility rule was added so existing imports using the "old" path would still work. I don't think the old...

Hi @barakmich, Thanks for creating this tool! I think it would be nice if go-nyet would be usable as a superset of go-vet directly, in the same way `goimports` and...

I found this thread useful, as I had the same problem. For future readers, this is the protoc command in my Makefile. Note that the `M…` and `plugin=grpc` options cannot...