Caveats if go package name doesn't start with github.com?

Question

I've recently started using go and planned to use following directory structure for my code: src/mycompany.com/project (so package name would be mycompany.com/project/component), however during code review my coworker (who worked with go before) pointed out that it's a convention to place code in src/github.com/mycompany/project (so package name would be github.com/mycompany/project/component).

I can understand that this is convenient for personal projects, but it looks weird to me to have it for company projects. Why does it matter which source control website company is using? What if company will decide to move to bitbucket later on - should all projects be refactored to have package names starting with bitbucket.org?

It is definitely possible to not use github.com: kubernetes have package name starting with k8s.io/kubernetes, and go book has package names which start with gopl.io (and both use github).

Question is: are there any caveats if package name doesn't start with github.com? E.g. maybe dep won't work properly (go get seems to work fine) or something else?

Also: what is the right way to have package name mycompany.com/project and have source code hosted on github?

Answer 1

If you set up the web server at mycompany.com to host your Go packages, there's nothing at all wrong with that approach.

But if the only reason to do that is to have "vanity" package names, it's probably not worth it.

Put another way: Your package name must match its hosting location. If you're using GitHub to host your project at github.com/mycompany/foo then your package name is github.com/mycompany/foo--there's no choice in the matter.

If you want to host your software on GitHub but still use mycompany.com as the package name, then you could set up GitHub to host mycompany.com's web page using the GitHub pages feature. But if you're an established company, then you probably already have your site hosted elsewhere, and it's not an option to move hosting to GitHub. And even if you don't already have a company web site, there's practically no reason at all to do this for the sake of Go packages.