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.
Honestly, most package managers just bring their own problems. I'd rather commit source code than troubleshoot npm, pip, nix, maven, etc errors all day long. The only package manager I've found that works reliably has been Cargo (Rust).
There has been a lot of talking between the committee that created `dep` and folks who've implemented other systems, including Cargo. I have high hopes.
I believe the current intended use is a human-editable "manifest file" where you specify desires/intent, preferably semver, ideally only as necessary, and a machine-generated "lock file" which specifies the actual hash of every transitive dependency, so builds are fully specified and reproducible.
But they all have to vendor as well if they want reliable builds. Otherwise you end up with everything breaking when a developer decides to do a forced push or take his repo off github.
Force pushes - by far more common than straight-up repository removal - are handled without problem; we let you stick with your old version. (At least, that's how it should be - there might be a couple more test cases to write. I know I designed for this problem early on).
Repo removal, renaming, or whatever, are still problems, for sure.
Today, dep populates vendor/ with dependencies, and works equally well whether you decide to commit them or not.
When dep removed the vendor folders from the other libraries, How does dep handle multiple libraries that depend on the same library but different versions of it?
What I don't get is why more folks don't just use per-project GOPATHs.
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.
> What I don't get is why more folks don't just use per-project GOPATHs.
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.
What do you mean 'that's not how go works'? Go provides GOPATH: using a different GOPATH for each of my projects works, and it works really well.
> You need extra work to make it work.
What extra work? I set GOPATH, and everything just works. What more is there?
> That's not up to debate anymore anyway
Neither were type aliases, until they were, except they aren't.
I have no idea what dep adds that using the standard GOPATH doesn't do: I've read the background and the docs, and I'm familiar with using the vendor directory in the past; frankly, now that I've switched to using GOPATH all of those things look like a mistake. It all reads like tha Javafication of Go.
Glide lets you pin dependencies to specific commits (the "version" key takes a semver version constraint, a branch name or a commit hash), and transitive dependencies will be pinned via the lockfile, so it works even if the implicitly included dependencies don't use versioning.
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.
yeah, this is one of the main pain points there. the reason it's so difficult to solve in glide is intrinsically tied to the engine glide uses for version selection - otherwise we'd have dealt with it long ago.
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.