
A Roadmap to Merging 'dep' into the Go Toolchain - numo16
https://github.com/golang/dep/wiki/Roadmap?utm_source=golangweekly&utm_medium=email
======
joaodlf
This can't happens fast enough.

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.

~~~
garfij
I haven't used Glide (only govendor) so I'm not sure exactly how it works.

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.

~~~
joaodlf
Commit hashes seem to be the way to go, for sure, at least to be safe. I
really don't want to put our vendor content in the repos.

It's just a tad absurd when you're used to mature package managers in other
languages.

~~~
weberc2
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).

~~~
zellyn
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.

~~~
sdboyer
indeed, we've talked with them quite a bit :)

------
ernsheong
This podcast (iOS) is really worth listening. Straight from the horse's mouth:

"Dependency Management, Semver, and Community Consensus"
[https://itunes.apple.com/my/podcast/go-
time/id1120964487?mt=...](https://itunes.apple.com/my/podcast/go-
time/id1120964487?mt=2&i=1000382116565)

It explains how go dep fundamentally works alongside the other tools.

~~~
OrangeTux
Web version of same podcast
[https://changelog.com/gotime/36](https://changelog.com/gotime/36)

------
zellyn
If you have any skills or interest in this area, the dep team could use your
help. Even just trying it out, running into trouble, and filing bugs would be
helpful. Join #vendor on the Golang Slack.

------
geodel
Great initiative. If it goes well we hopefully will have an integrated
dependency management solution with go command by next year this time.

------
devty
The `dep` repository:
[https://github.com/golang/dep](https://github.com/golang/dep)

------
ernsheong
This podcast (iOS) is really worth listening. Straight from the horse's mouth:

"Dependency Management, Semver, and Community Consensus with Sam Boyer"
[https://itunes.apple.com/my/podcast/go-
time/id1120964487?mt=...](https://itunes.apple.com/my/podcast/go-
time/id1120964487?mt=2&i=1000382116565)

------
vkat
Started with dep recently on a real go project at work. It worked initially
fine until I started adding dependencies and I had to hunt down the right
commit hash by looking at the dependencies. I am probably going to stick with
it and maybe contributing upstream as well.

------
politician
Anyone know how dep's approach differs from the two-step process in `gb`?

(gb vendor fetch github.com/some/pkg, gb build, git commit -am "all of your
vendor'd source")

~~~
sdboyer
sadly, gb is one of the extant systems i haven't had a ton of time to explore.
but...

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`).

~~~
mappu
`gb` has a package-management-only version in `gvt` by @FiloSottile .

------
cybernytrix
Our team runs _the_ largest Go middleware. Checking in external dependencies
into your repo scales - you don't want 200+ users hitting Github every 10
minutes, when you can hit the local Git repo on a 10Gbps n/w. Also, using
GOPATH with a simple Makefile is pretty much all you need -- unless you don't
grok Makefiles. But whatever floats your boat and as usual the latest hotness
sells.

------
poofyleek
I use gopkg.in. Personally I would like to see the community avoid adding more
to the 'go' tool. It is already doing too much. I think the solution provided
by gopkg.in is better than other more conventional methods (e.g. npm or maven
like). I love Go. But it is ironic that 'go fmt' was designed in from the
beginning. And now we are still dealing with semver and package dependencies.
I went with gopkg.in because it made the dependencies a non issue from the
tooling point of view. It is made possible by having 'import' direct from the
repositories, which archive different versions and tags. Perfect for something
like gopkg.in. I am probably in the minority.

~~~
lobster_johnson
You say you don't want the go tool to be more complex -- but gopkg.in just
moves dependency management elsewhere. You have to have it somewhere.

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?

~~~
michael-go
another problem with gopkg.in it uses only the major version number and you
can't import a specific minor version. what if version 2.5 works great but 2.6
breaks something for you? you can't use pkg.in until this issue is resolved in
2.7 .. and most package authors don't want to bump the major version on every
change ..

