Hacker News new | ask | show | jobs
by politician 3393 days ago
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")

2 comments

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

`gb` has a package-management-only version in `gvt` by @FiloSottile .
In summary, via gb:

    git add vendor/ && git commit
In dep:

    echo vendor >> .gitignore
Ie. Dep is designed to easily restore specific versions of packages online, like other package managers. Gb expects you just commit them.

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.