Golang import path best practice

珍惜时间，勤奋学习！今天给大家带来《Golang import path best practice》，正文内容主要涉及到golang等等，如果你正在学习Golang，或者是对Golang有疑问，欢迎大家关注我！后面我会持续更新相关内容的，希望都能帮到正在学习的大家！

问题内容

I am currently working on a private project using Golang (and I am new to it).

But I have the problem that I don't know what is the proper way to define the import path for local packages.

I have the same feeling as the author from this link https://medium.com/@c9s/golang-the-annoying-remote-import-path-c6c7e76517e5

In short, if I host a project foo in Github. I feel strange to use github.com/levin/foo as import path instead of just foo. Wouldn't it cause much rework if I move my codes to Bitbucket or I host my own git server in AWS?

And worse, I can rewrite my code to change the import path, but how would people using my code in theirs notify the change of repo? And I feel no sense to ask others to update their codes.

I am new to Golang so feel free to say something like "your question is not even valid".

正确答案

The answer to your question:

I don't know what is the proper way to define the import path for local packages.

As @JimB said:

If you want to use the Go tools you need to follow the conventions. If you want go get to work, then you need to import it with the full name, otherwise put it wherever you want in GOPATH

So you need to use the complete import path github.com/levin/foo if you want go get to work, and you should do it this way if you expect other people to use your package.

The answer to your second question:

Wouldn't it cause much rework if I move my codes to Bitbucket or I host my own git server in AWS?

There is a way to use a custom domain name as import path and still host your code wherever you want, it's called a vanity import path I think. You just need to add some meta tags to the html file that gets served in the import file that you use.

This article explains how to do it, but in summary, in the file that gets served in your custom domain when the custom import path is accessed, you need to add a go- import meta tag that points to where you hosted the code. The article uses github.com/foo/bar as example of where you are hosting your code and foo.com/bar as your real import path.

So in the file that gets served when accessing foo.com/bar there should be a meta tag like this:

And you continue to host your code in github. Then if you change the hosting place to your code you just change the value of the meta tag, but all the code that uses the package continue to use the exact same import path "foo.com/bar.

The only issue with this is that now your project can get imported by 2 different paths: foo.com/bar and github.com/foo/bar. To fix this they have canonical imports which only allow the package to be imported using the custom path and not the github one, it's only adding a comment next to the package name on each package file:

package bar // import "foo.com/bar"

This is the only way to avoid the issue you have. You can use @srxf answer if you are using a package that is just going to be used locally just know that the go tools are not going to work with that code (like go get). If you want the code to work as it is intended then this is the way to go.

As a comment, I know it feels silly importing github.com/levin/foo for a local package, but if you use that package in another package (say foo2) and someone else imports foo2, this allows the compiler to know exactly where to get the dependencies for foo2, because all the import in the code include the whole route, not the name of a local file. This way people can always get the dependencies they need for your package without having to include those files in your repo, and without having to configure anything for it to work. It's not perfect but it's the way go works, they call it convention over configuration or something like that.

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。