FAQ
Re: this announcement, I should probably mention that there's
another solution in this space that we've been using in production
for a good while now: launchpad.net/godeps. It actually predates
Keith Rarick's godep. It's somewhat simpler that most other
tools (some might say it's a bit simplistic :-]), but it works for us.

By convention, we save dependencies in the top level
of a project with:

     godeps -t ./... > dependencies.tsv

The output has one line for each dependency (one
per repository, not one per package) holding a tab-separated
tuple (path, vcs-type, hash).

We update dependencies with:

    godeps -u dependencies.tsv

That's it, pretty much.

Here's its usage message:

Usage:
godeps [flags] [pkg ...]
godeps -u file [flags]

In the first form of usage (without the -u flag), godeps prints to
standard output a list of all the source dependencies of the named
packages (or the package in the current directory if none is given).
If there is ambiguity in the source-control systems used, godeps will
print all the available versions and an error, exiting with a false
status. It is up to the user to remove lines from the output to make
the output suitable for input to godeps -u.

In the second form, godeps updates source to versions specified by
the -u file argument, which should hold version information in the
same form printed by godeps. It is an error if the file contains more
than one line for the same package root. If a specified revision is not
currently available, godeps will attempt to fetch it, unless the -F flag
is provided.

   -F=false: when updating, do not try to fetch deps if the update fails
   -P=1: max number of concurrent updates
   -n=false: print but do not execute update commands
   -t=false: include testing dependencies
   -u="": update dependencies
   -x=false: show executed commands

cheers,
    rog.

On 5 August 2014 14:48, robfig wrote:
Announcing a vendor-less dependency management tool.

https://github.com/robfig/glock

## Overview

This one is very simple. It provides 2 commands and a version control hook:

"glock save project" writes the transitive root package[1] dependencies of
all packages under "project/..." to a GLOCKFILE
"glock sync project" updates all packages listed in project/GLOCKFILE to the
listed version.
"glock install project" installs a version control hook that watches for
changes to project/GLOCKFILE and incrementally applies them.

Glock is similar to "godep -copy=false"

GLOCKFILEs are simple text files that record a root package's version, e.g.

bitbucket.org/tebeka/selenium 02df1758050f
code.google.com/p/cascadia 4f03c71bc42b
code.google.com/p/go-uuid 7dda39b2e7d5
...

## Workfow

Here's the expected flow for working with a Glock-managed repo:

Clone the repo
"glock sync" your GOPATH
"glock install" the hook
"glock save" when you add/update a dependency


## Use case

At work, we keep our Go code in one repo (rather than many small ones) and
use a single GOPATH. This tool allows us to gain reproducible builds, with
version updates automatically propagated to the team via the hook, with the
following advantages:

We still use the normal Go toolchain / dev process (e.g. not having to run
everything in a godep sandbox). We can more easily contribute to 3rd party
libraries, since they are not in a vendor sandbox or have rewritten import
paths.
We avoid the repo bloat of checking in our dependencies (> 100 MB), in
addition to the extra churn. Updating a dependency involves a change to one
line of a text file instead of thousand-line diffs.
Much easier and less error-prone than manually checking in dependencies.
Developers don't have to fight git because git wants to make the project a
submodule instead of just checking in the files. Running glock on your CI
server or as a pre-commit hook can ensure that any new dependencies have
been recorded.

Hope it's useful for others as well. There is some more information in the
README

Questions / comments?

-Rob

[1] "root package" refers to the base package in a repository. For example,
although code.google.com/p/go.net/websocket is a Go package,
code.google.com/p/go.net is the "root package", and any dependencies on
non-root packages roll up to the root.

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 15, '14 at 2:27p
activeAug 15, '14 at 2:27p
posts1
users1
websitegolang.org

1 user in discussion

Roger peppe: 1 post

People

Translate

site design / logo © 2022 Grokbase