3 ms·

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

• sdboyer 10y ago
  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 10y ago
    `gb` has a package-management-only version in `gvt` by @FiloSottile .
• shadowmint 10y ago
  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.