search

patrickmn / go-cache

An in-memory key:value store/cache (similar to Memcached) library for Go, suitable for single-machine applications.
https://patrickmn.com/projects/go-cache/
MIT License
8.16k stars 874 forks source link

Add go.mod file declaring proper semantic import path #89

Closed m90 closed 6 years ago

m90 commented 6 years ago

As the latest version is tagged as v2.x.x in git, using the package as a Go module will require importing it as github.com/patrickmn/go-cache/v2, otherwise it will show up as:

github.com/patrickmn/go-cache v2.1.0+incompatible

in a dependent's go.mod.

See: https://github.com/golang/go/wiki/Modules#semantic-import-versioning

I know it's not pretty and introduces more things to maintain manually, but apparently it's what is supposed to be done in this context.

patrickmn commented 6 years ago

Yeah, this is pretty annoying. Ironically it's making me think we should just revert to <2.0.0 somehow, since the API difference between 1.0.0 and 2.0.0 is extremely small (*Item changed to Item with integer expiration times) and go-cache is essentially stable and has been for years. I realize the irony, but this seems preferable to asking all users of go-cache to add a version to their imports...

Unless I'm mistaken, if I merge this PR, the vast majority of people using Go 1.11 will suddenly revert to go-cache 1.0.0, something that's totally unnecessary and would decrease performance, all because of a tiny API difference in a corner nobody touches.

Is there a way to tell go mod to use 2.0.0 as the default?

m90 commented 6 years ago

Unless I'm mistaken, if I merge this PR, the vast majority of people using Go 1.11 will suddenly revert to go-cache 1.0.0, something that's totally unnecessary and would decrease performance, all because of a tiny API difference in a corner nobody touches.

I don't think it'll be the vast majority right now as with Go 1.11 the module behavior is still opt-in (you have to work outside GOPATH or do GO111MODULE=on), so it should only hit people who do actively migrate. I would assume though that Go 1.12 turns on modules by default, so the issue you describe will most likely become an annoyance for everyone in 6 months time. So, yeah.

Is there a way to tell go mod to use 2.0.0 as the default?

I couldn't find anything on this topic. This is what go help modules will tell us about the situation (which leaves me wondering what the right thing to do is and what the actual implications of +incompatible can be):

Code written before the semantic import versioning convention was introduced may use major versions v2 and later to describe the same set of unversioned import paths as used in v0 and v1. To accommodate such code, if a source code repository has a v2.0.0 or later tag for a file tree with no go.mod, the version is considered to be part of the v1 module's available versions and is given an +incompatible suffix when converted to a module version, as in v2.0.0+incompatible. The +incompatible tag is also applied to pseudo-versions derived from such versions, as in v2.0.1-0.yyyymmddhhmmss-abcdefabcdef+incompatible.

This is a similar issue in another repo I found: https://github.com/gofrs/uuid/pull/44

Maybe it's best not to merge this now (as there are no pending updates from what I understand) and keep an eye on how other package authors / the community starts dealing with the problem at hand.

m90 commented 6 years ago

This looks like a good thread on the topic: https://github.com/golang/go/issues/25967 which sounds as if doing nothing is an ok choice in this situation (see this comment).

patrickmn commented 6 years ago

Thank you for the info.

I wish they'd gone with "nomod" or something over "incompatible". It makes it sound like go-cache is broken now.

m90 commented 6 years ago

Yeah the naming is very unfortunate as it implies something is not working as intended. Anyways...