7

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?

yname
  • 2,189
  • 13
  • 23
  • 4
    `go get` knows about some code hosting sites (githubs is just one built into go get) and can work with almost any others by via HTML meta tags. Read about it here. https://golang.org/cmd/go/#hdr-Remote_import_paths. So probably you might want to call you package git.mycompany.com/projeckt if you host it e.g. with gitlab. – Volker Apr 15 '18 at 06:55
  • 2
    To give you a concrete example for the HTML meta tags Volker mentioned, this is our server which directs Go to get packages named go.example.com/foo/bar from gitlab.example.com/foo/bar: https://play.golang.org/p/qMVM_lZ_xjc. go.example.com and gitlab.example.com are different machines. In fact, for some packages it will return GitHub repositories (not shown in the code). – Peter Apr 15 '18 at 10:12
  • @Volker I think that's what I was looking for. I'll accept it as the answer if you'll move your comment to an answer. Thanks! – yname Apr 17 '18 at 05:36

1 Answers1

5

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.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189