Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
doc: import aliasing clarification #34603
Looking at the documentation about dealing with import collisions, the code review comments document says:
Indicating that the packages in the local repository should be aliased, rather than external packages.
Meanwhile, the Effective Go section on package names says:
Which reads to me in opposition to the code review comments recommendation; suggesting the imported (external) package should be aliased, not the local package of the same name.
I tried to find some more information about a "why" for either of these recommendations in the issues and PRs here, but came up empty..
Could I be so bold as to request some further clarification of the recommendation?
Thanks in advance!
You should prefer not to rename the less-project-specific import because, all else equal, another reader of the code is more likely to me familiar with that package, and thus more likely to understand the original name without further context.
The word “locally” in Effective Go is referring to the name that is used “locally” within the importing source file, not the locality of the package being imported. (It's telling you that some package can be renamed, not indicating which one should be renamed.)
Thanks @bcmills, that makes sense. Appreciate the quick & concise explanation!
Now that you've mentioned:
It is clearer that it is more so talking about third-party/open-source packages that might be well known. We were looking at imports of our own (private) packages and felt that the opposite made more sense to us when names collide.
For example, we might have 2 packages
Would you say this still a bad idea and the local package should actually be the aliased one?
I would say that if one of the colliding packages is closed-source and under your control, you should change the package name instead of renaming it during import.
See https://blog.golang.org/package-names (especially the “Avoid unnecessary package name collisions” part).