Structuring Go subpackages for teams

We are currently moving some of our codebase to Go and are struggling a bit with a flexible directory structure for multiple devs within a team. Apologies if this is a noob question but I’ve searched everywhere else and not come up with an answer.

Say I have a package with the following structure:

package main

import "username/myproject/subpackage"

func main() {

}

and a subpackage:

package subpackage

func main() {

}

This works fine and from reading other peoples code on Github, it seems like this is the accepted way to define subpackages.

See the CoreOS source as an example: https://github.com/coreos/etcd/blob/master/main.go

My problem is that due to the directory structure of Go, these packages are stored within a specific git repo and if someone else in the team checks out this code to work on, their directory structure will be different due to forking. The username in the paths and the import statements will change. This isn’t helped by the fact we pull and push a lot to each other rather than using a centralised repo.

package main

import "otherusername/myproject/subpackage" (This line will have to be changed)

func main() {

}

Everything I have read about Go points to its usability in team environments so I’m wondering if I’m understanding the package system properly.

Ideally we would like to be able to call subpackages with relative paths. We are used to working with namespaces and I know Go doesn’t have them. ie:

package main

import "myproject/subpackage"

func main() {

}

But Go can’t find the file and I’m sure it’s not the right way of doing it as no examples online use relative paths.

So a couple of questions:

  1. Should packages have a defined owner and always keep that username as part of the import paths?

  2. Should this “owner” repo be a centalised repository (say a company or organisation) that all code is pushed to / pulled from?

  3. Should other team members working on a piece of code use it within the creators folder/namespace rather than their own?

  4. Is there a way to define relative paths in import statements, and if so, why does no-one do it? Is it considered bad practice?

  5. How is repo forking handled with Go subpackages?

Thanks.