I can't be the only person who thinks Go is really interesting, but can't get over the 'package' hump... It's just too wonky for 'real-world' from my experience. For example, how do you create clear lines of separation with internal modules? If you want to use 'namespaces' then each namespace has to be it's own package, which then requires its own Repo that you have to 'go get'. There's unsustainable for a project of any useful size.
Packaging is both the best and worst of Go. I love the decentralisation, so there's no central directory of Go code. We don't have pypi, we don't have rubygems or npm, we have Github.
As others have pointed out, you can use directories as namespaces, which works nicely. But I've found, personally, that splitting my projects into separate repos for each namespace is actually beneficial. Helps keep my code clean and separated.
That being said, versioning is a real pain right now. The best thing I've found is to fork a repo when I decide to use it, then pull in updates as I adjust my code to work with them. Definitely not ideal, and if you have a lot of projects using the same dependency, it becomes a major headache.
There are some workarounds, and we've discussed the topic at great length on the mailing list. I think it's something we'll see a solution to in the next few years. But one of the things about Go that I really enjoy is that the core team is hesitant to push half-baked ideas onto the community. When we see a solution, it tends to be an elegant, clean solution that fits perfectly into the problem it solves.
In other words: yes, there are some problems. Yes, I do think they'll go away. Yes, I do think we'll need to be patient. Yes, I do think it will be worth it.
Organize your packages in a directory tree. You can check the entire tree into a single repository. There's no requirement to put the code in a repository or use 'go get'.
Each package does not need to be in its own repo. You can put packages inside subdirectories. The standard library is full of these, such as the net library. There is the net library itself, and there are subdirectories, including http, smtp, and more.
I would imagine this has something to do with having an existing package dependency management system company-wide and it causing friction trying to get the two to coexist.
I have similar issues where I work with trying to integrate an internal build system and rubygems. Our answer is to essentially mirror the gem version internally into our own repo. It's not the best answer I could hope for.
Absolute import paths are preferred. If the import path for the importing package is [app], then import the package using `import "[app]/[internal_module]"`.
They can all be subdirectories of the same main repo, yet import each other with paths like github.com/mainrepo/packagename.
The real thing that I haven't figured out a consistent solution to is how to manage versions. You could approximate version numbers with branches or tags, but nobody's put together a convention for it that works well with the tooling. That'll be important as go matures and has more libraries.
I must be missing something.