gopkg import with the mocks subpackage

[aaronkavlie-wf]

The mocks subpackage imports github.com/Shopify/sarama. The README suggests using gopkg.in (which github.com/wvanbergen/kafka does), but it leads to conflicts when using mocks like so:

cannot use "gopkg.in/Shopify/sarama.v1".NewConfig() (type *"gopkg.in/Shopify/sarama.v1".Config) as type *"github.com/Shopify/sarama".Config in argument to mocks.NewSyncProducer

[eapache]

Hmm, cc @wvanbergen this is actually kind of annoying; if we switch the import paths for the mocks to use gopkg, then it will break for anybody using master directly (of which there are at least a few)...

[eapache]

It might be possible to work around this via https://golang.org/doc/go1.4#canonicalimports? I'm not 100% sure, I think it depends on exactly how gopkg.in proxies the repo.

[wvanbergen]

/me suppresses rant about the shitty package management tooling in go.

I don't know how that would work. Based on those docs, adding a canonical import path will just make one of the two locations fail. gopkg.in would have to do some rewriting as part of the proxying for it to work, but that is kind of against the idea of a canonical import path.

[wvanbergen]

maybe we can just use a relative import? import './mocks'

[eapache]

Relative imports break go get and a bunch of other things, I think... maybe worth trying though to see?

[fgrosse]

Unfortunately it seems like there is still no real solution to this issue yet. Here are my thoughts:

Did you consider moving the mocks into the github.com/Shopify/sarama package directly? There are no extra dependencies this would introduce there and just simplify the code and imports. This change could be introduced under a new major version (i.e. gopkg.in/Shopify/sarama.v2) since moving the mocks package obviously breaks BC.

Of course this would break all users that import the github repository directly but if this is actually an issue for the library then I wonder why you are using gopkg.in in the first place. Maybe the actual solution should be to stop advertising the usage of gopkg.in alltogether?

[varun06]

I wonder if this is still an issue with go modules?

[ograycode]

Yes, I believe so @varun06

[dnwe]

@bai since Sarama requires go modules for some time now, is there any benefit to still using gopkg.in anymore? Perhaps we should enable the canonical import path of github.com/Shopify/sarama everywhere?

[bai]

@dnwe I'm 👍for this change.

[ghost]

Thank you for taking the time to raise this issue. However, it has not had any activity on it in the past 90 days and will be closed in 30 days if no updates occur.
Please check if the master branch has already resolved the issue since it was raised. If you believe the issue is still valid and you would like input from the maintainers then please comment to ask for it to be reviewed.

[dnwe]

Closing this as outdated, please re-open if you still think there is something we can do here