- you can use only git dependencies (no bzr, hg, ...); though most stuff is on github nowadays (especially with closure of Google Code), still not necessarily everything. With pure submodules you're locking yourself in the git monoculture.
- you must trust your dependencies will not ever disappear (see "the leftpad problem", or the mentioned closure of Google Code).
That said, all approaches have pros and cons. Though I admit I usually don't like advertisements which only show advantages and don't list downsides.
Personally, I like glide better since it takes a lot from Ruby bundle. I commit only glide.yaml and glide.lock in the repository. It is not flawless either as each operation triggers an update of all dependencies.
(see: http://blogs.atlassian.com/2013/05/alternatives-to-git-submo... and https://codingkilledthecat.wordpress.com/2012/04/28/why-your... )
I haven't found anything on the conference site.
There's a collection of tools for managing that, like this one , and others like "godep" and "glide". Which one you use for that doesn't seem to be settled.
> Some copy the source code of dependencies into the vendor directory:
I don't agree with any of the stated problems there. Unless you are building a library you should commit your dependencies and not rely on third party repos being available.
I can't stress enough how useful govendor  is if you do Go professionally.
You could fork the dependencies that you work with into locally managed repos and use submodules to include them in your own project. That way you can easily update your dependencies without breaking everything and also maintain their commit history.
If you depend on A and B and both depend on C, you now have the npm2 style heirarchy of nested dependencies.
As with all 'use submodules' solutions, the devil is in the detail with the nested heirarchy of dependencies and version resolution.
I mean, fwiw, its quite nice for simple 1-level-deep dependencies, but this isnt a simple problem. What if A -> C@1.1.5, and B -> C@1.1.9. Do you install both? Only one?
You might still be able to solve it somehow, if the submodules are required to have semantic version tags on their versions, you parsed the entire hierarchy and then resolved conflicts (somehow), based on the semver semantics... I guess?
This tool just tries to help you manage that. Not that I'm a big fan, either way, but still.
Package manager shouldn't be that thing, that tries to integrate into existing fragile environments. It should be the thing that manages those environments, that manages all the compilers and libraries in a reliable and reproducible way, with rollbacks and everything.
I guess those aren't easily embedded in a GitHub readme though. Alas.
> Packaging and deployment aren't problems in Go OR Python if you're only solving trivial problems.
> With a larger project, you might have an easier time packaging and deploying Go code, but that's largely because there are no libraries to package. Admittedly packaging can be a pain in Python, but that's usually because of poor choices in dependencies. Packaging Python with a few mature dependencies isn't hard in my experience. It's the projects where some idiot has pulled in every 0.x versioned library in pip that are hard to package. When Go has as wide a variety of libraries as Python people will run into the same problems in Go.
> You could argue that at least for now Go doesn't allow you to shoot yourself in the foot that way, but I'd rather have the option.
> I'm not defending Python in particular here. I'd say the same things I've said here about any mature language with extensive libraries.
> If you're espousing Go because of easy packaging and deployment, I strongly suggest that you consider whether that's actually a feature Go will have long term, and whether you're currently paying for that feature by having no libraries available to you. The only lesson I would take away from Go's easy packaging is to only use mature dependencies that pull their weight.
And in a different post:
> give it a decade and Go packaging will be just as miserable as packaging in any other language.
I've been coming up against that argument a lot less lately. It looks like my prediction is coming true a bit ahead of schedule.
I hope this comes before the end of the year. This has been put on the back burner for too long and I can understand GC was priority but now GC is very good.
Not ideal, but not a deal breaker either.
Edit: IMO it's a deal breaker
And yes, it's annoying, but a workaround exists.
Why the reluctance to add ALL SOURCE REQUIRED TO BUILD YOUR APP to your source repository. I don't get it.
Also, no matter what vendor tool you use, please use one such that I can "go get" your command (main package).
Although we're really at the point where I don't care what tool is used, so long as the community can pick one.
That would make the Git history incredibly messy to work with and makes the repository much larger in size, making work slower. This kind of "monorepos" are known to be a pain in the ass with Git.
However, Git submodules is pretty much adding all the required source code (or at least pointers to) in your repo, and pinning them to a specific version.
The network connectivity issue is solved by having local mirrors.