I have been having a fantastic time with Go... Up until the point I have to add a new package to my projects and go through CI and deployment.
Glide works mostly OK, but it's not the final solution, that's for sure. Even big packages on github fail to produce releases, so you have to depend on master branches... One day your builds just decide to break. It's a nightmare.
Are you checking your dependencies into your repository (we do this, it works very well).
If not, are you pinning specific commit hashes? Is that even possible in Glide?
AFAIK those are the only two ways to get even close to reproducible builds.
It's just a tad absurd when you're used to mature package managers in other languages.
it work if you are working on a project, it does not if you are library author who rely on other dependencies.
I have all my stuff in $PROJECT/src/$PROJECT, and all the dependencies are git submodules in $PROJECT/src/, and it all Just Works. Perfectly. git submodule is a bit of an annoyance, but it works. Anyone fetching my project just checks everything out, and it all Just Works™.
It's a lot better than using a dependency-management tool and shared GOPATH, at least in my experience.
because that's not how go works. You need extra work to make it work. That's not up to debate anymore anyway, dep will be the official package manager and will be merged with the rest of the official ecosystem.
The main problem with Glide is that it's buggy. It also lacks some important features. You still can't do "glide update" on a single dependency, for example. It's all or nothing.
"Dependency Management, Semver, and Community Consensus" https://itunes.apple.com/my/podcast/go-time/id1120964487?mt=...
It explains how go dep fundamentally works alongside the other tools.
"Dependency Management, Semver, and Community Consensus with Sam Boyer" https://itunes.apple.com/my/podcast/go-time/id1120964487?mt=...
(gb vendor fetch github.com/some/pkg, gb build, git commit -am "all of your vendor'd source")
i guess the analogue to what you're describing would be
1. <add an import path> 2. `dep ensure` 3. `git commit -am "all of your vendor'd source`
a bit more detail, starting at a high level: gb is a replacement toolchain. dep is focused strictly on dependency management. there is no notion of a `dep build`.
with dep, there's no explicit command to actually fetch a dep; the import graph is still queen, as is customary in go. so there's no direct analogue to `gb vendor fetch github.com/some/pkg`. if you want to add a dep, import it in your source code, and run `dep ensure`. (there's some flux in exactly how that works right now, but what i'm describing is the state we're moving towards)
`dep ensure` is really the workhorse command, and pretty much the only thing you'll ever need to run. (in fact, the only three subcommands we currently plan on having are `init`, `ensure`, and `status`).
git add vendor/ && git commit
echo vendor >> .gitignore
Practically speaking I guess the manifest that dep uses makes it easier to see at a high level exactly what versions of what packages are installed and from where.
gopkg.in only works properly if everyone uses it. The second you have a non-gopkg.in package, you have no way to manage that dependency.
Does gopkg.in work for non-public libraries?