Naming clash for new cmp standard package
Carrotman42 opened this issue · 4 comments
I am not sure where the best place to have this discussion is, but I wanted to get @dsnet's opinion on this so this seemed like a reasonable place to start.
This is an extremely popular package and is imported into many Go tests across the world. Unfortunately, the new cmp package added within the last year has the same name as this package. I can see one possibly likely scenario where I would want to import both packages: in a unit test which wanted to use cmp.Diff along with a cmpopts.SortSlice which used cmp.Less[sometype]. There may be other situations as well.
The general solution to two packages having the same name is to rename one of them, but it isn't clear exactly which should be renamed: while it seems like a package in the stdlib is more central (leading to a preference to rename the third-party go-cmp), since go-cmp predates std/cmp by many years it will be a burden to retrain people with this new rename rule.
Does this package (or its maintainers) have an opinion about how to handle this naming clash?
PS: One out-of-the-box idea I had was to add forwarding code in go-cmp to all things in std/cmp, but I think that would cause people to import the heavier-weight go-cmp package into non-test code by accident so I am not certain that's a great idea.
The name collision is unfortunate and was brought up during the proposal for the stdlib "cmp" package. The concern was dismissed as not being a problem: golang/go#59488 (comment)
Adding "go-cmp/cmp" to the stdlib has been proposed before, but rejected: golang/go#45200
I personally still find the name collision unfortunate, but don't see the benefit of just renaming "go-cmp/cmp" worth the cost in churn. If we were to do a v2 of the package or entirely move it elsewhere (e.g., the stdlib), there there might be enough benefits to warrant a rename as well.
\cc @neild if he has thoughts.
The standard library cmp is obviously not being renamed.
We could rename github.com/google/go-cmp/cmp. But that's a lot of churn and confusion, for a questionable benefit.
I think the best thing to do for now is wait and see. Perhaps this isn't an issue at all, or is a minor one. We'll have more information in a year or two.
I wonder how big of a problem that is in practice?
There's plenty of third party packages that clash with package names in stdlib too. Many libraries have their own errors package for example, that export the errors they use. Or a log package.
Any code base that's not already using stdlib's cmp can switch the import to gcmp "github.com/google/go-cmp" and now you can import cmp as normal. Or import stdlib cmp as stdcmp "cmp", though that one is bound to cause more confusion over time.
It may be possible to provide a go fix for the first approach that aliasses the go-cmp import?