tools / godep Goto Github PK

The restore command has unclear documentation.
See the discussion below for an example of the
confusion this has caused.

Original issue description follows.

In the course of working on my primary project, I sometimes also need to make changes to a package P that I depend on. It'd be nice for godep to help with that workflow.

What I'd like to do is something like this:

• Change P; run P's tests.
• godep save to copy over the WIP changes.
• Run my tests, to make sure the change is what I really want.
• Commit the changes to P.
• godep save to copy over the final changes.

However, godep save bails out with ""dirty working tree". I'd like to be able to force the copy (with -f, perhaps?). Without something like that, I need to either commit to P constantly or make changes to my local copy and then manually backport them.

There is the question of what to put in Godeps.json. It doesn't matter too much, since it should never get committed but options include (a) letting the vcs to provide the string for us, (b) just append -dirty, (c) add a "dirty": true key. I'm inclined towards (c), since it'll be most visible in diffs, but (b) seems reasonable as well. Either way, an accidental restore of a dirty commit ought to fail loudly.

I have these two imports:
"github.com/iron-io/iron_go/api"
"github.com/iron-io/iron_go/config"

I have this code:
// Configure the call
config := config.Config("iron_worker")
config.ProjectId = this.IronIo.ProjectId
config.Token = this.IronIo.Token

The config.go file from the iron_go/config package is not being imported. The api.go file from the iron_go/api package is?

Steps to reproduce:

$ mkdir -p $GOPATH/src/github.com/foo/bar
$ cd $GOPATH/src/github.com/foo/bar
$ printf 'package main\nimport _ "labix.org/v2/mgo"\nfunc main() {}\n' >main.go
$ go get labix.org/v2/mgo
$ godep save -copy

Expected output: no output (success)

Actual output:

godep: dirty working tree: /Users/kr/src/labix.org/v2/mgo
godep: error loading dependencies

https://github.com/mitchellh/gox

I can use this to cross compile.
Example: gox -osarch="linux/amd64"

Would like to:
godep gox -osarch="linux/amd64"

In hk, I recently added an IsANSI() func in the github.com/heroku/hk/term package.

With a fresh clone of this project and a godep go build, I see the following:

➜  hkstaging-build git:(staging) ✗ godep go build
# _/private/tmp/hkstaging-build
./main.go:187: undefined: term.IsANSI
godep: go exit status 2

Note that this is on Darwin, and the local file in ./term/unix.go definitely contains the IsANSI() function. I dug a bit and noticed that I had a stale local binary object from this subpackage:

➜  hkstaging-build git:(staging) ✗ ls -la ~/go/pkg/darwin_amd64/github.com/heroku/hk/
total 536
drwxr-xr-x  4 bgentry  staff     136 Jan 17 13:10 .
drwxr-xr-x@ 5 bgentry  staff     170 Jan 17 13:10 ..
-rw-r--r--  1 bgentry  staff  225050 Jan 17 13:10 postgresql.a
-rw-r--r--  1 bgentry  staff   48476 Jan 17 13:10 term.a

Once I changed into my subpackage's dir (~/go/src/github.com/heroku/hk/term) and ran go install, this binary object was updated:

➜  hkstaging-build git:(staging) ✗ ls -la ~/go/pkg/darwin_amd64/github.com/heroku/hk/
total 536
drwxr-xr-x  4 bgentry  staff     136 Feb 10 13:32 .
drwxr-xr-x@ 5 bgentry  staff     170 Jan 17 13:10 ..
-rw-r--r--  1 bgentry  staff  225050 Jan 17 13:10 postgresql.a
-rw-r--r--  1 bgentry  staff   49134 Feb 10 13:32 term.a

Which allows the build to proceed normally:

➜  hkstaging-build git:(staging) ✗ godep go build
➜  hkstaging-build git:(staging) ✗

Is there something wrong with a build flag in my app, or is this something that Godep isn't accounting for?

I got a few errors when trying to add some dependencies:

$ godep save
godep: directory "/home/maciek/code/aux/go/src/github.com/heroku/observatory" is outside source root "."
godep: dirty working tree: /home/maciek/.gvm/pkgsets/go1.1/global/src/github.com/heroku/observatory/model
godep: dirty working tree: /home/maciek/.gvm/pkgsets/go1.1/global/src/github.com/heroku/observatory/util
godep: error loading dependencies

and noticed that the entire Godeps directory had been deleted afterward. It's not a big deal--it was in source control--but this is probably not a great behavior.

Possible experimental feature: copy source code for all dependencies
into the current repository, alongside the json manifest. The manifest
would indicate that all dependencies are expected to be present, and
using godep go on such a manifest would do none of its sandbox
constructing shenanigans, instead using the copied tree directly.

$ godep save -copy

Since all code has been copied in, there are no external service
dependencies at build time (no need to fetch code over the internet).
The tool still sets gopath to include this directory – the development
workflow is the same as original godep – so import paths do not
need to be rewritten.

$ godep go build # uses local copy if present

This also makes the implementation of godep go far simpler.
(And situations like the one in issue #10 would simply not occur.)
Enough so that, were this to work out nicely, I'd be tempted to make
this the default and only behavior of godep.

https://groups.google.com/d/msg/go-package-management/-rNvdrdPC-k/ofin3XevusYJ

@davecheney:

godep shell anyone?

@ardan-bkennedy:

That is an awesome idea. That could really help make things easy for everyone. People don't want to think, "just tell me what to do".

The shell could identify the Godep folder(s) within a workspace, automatically setup the GOPATH and everything would run. It could also intercept calls and perform magic when necessary. All the go tooling works without needing to type godep first. It could handle some of the harder problems I am sure.

This came up again during @fdr's testing.

For the pull, edit, update dependency, godep save, push cycle,
a godep restore command would make things much easier.

Original report follows.

So using different workspaces for dev and "build" leads to confusion. A tool which builds the working workspace, and can report errors in it, warn on unchecked stuff or wrong versions present, seems more useful than working purely on a sandbox. I think being able to make a temp workspace and run go commands is a great idea, but I want to use the same tool to manage my non-temp workspace :-)

It would be really useful if it would be possible to import private repositories using git+ssh for private github repositories for example.

I'm using Ginkgo, but this would be true for regular tests as well I reckon.

When running godep save, the resulting json does not include any dependencies that are only present in "_test" packages.

e.g. my code is in package foo, tests are in foo_test.

If foo_test imports github.com/onsi/ginkgo, but no non-"_test" package imports it, then ginkgo will be excluded from Godeps.

I've worked around this by moving everything out of "_test" packages for now, but that's not an ideal solution.

Thanks!

I'm not sure why this is working for others... I forked and took out the +1 on this line, in order to get it working (prior to that, it was putting everything in rc instead of src:

freeeve@608124b

godep holds a strong opinion about how the source tree of a project is managed. See https://groups.google.com/forum/#!topic/golang-nuts/8NJq6jTIpas. Like Frank, our repository contains the entire source tree (and more). This allows ut do have a company-wide Makefile that implements various policies and procedures useful to our workflow, and allows stuff related to the project to be stored in the same git repo (ex: Vagrantfiles). Also, we have a policy where all of our code must use the same dependencies.

In summary, this is our git repository structure:

/
/ops
/go
/go/src/company.com/proj1
/go/src/company.com/proj2

godep is incompatible with this structure. Example: cd go/src/company.com && godep save will fail with a "directory ../x/y/z/go is not using a known version control system", probably because /go is not the top-level directory of the repository.

godep has all of the other features we'd like in a dependency management system, but changing our model to support its requirements is too constraining for us. My request is that godep be adapted to support this pattern.

I had some extra files not checked in sitting in the dir of one of my local deps. When I ran godep save, these files got copied into my app's local workspace. This behavior surprised me. I would have expected to only see stuff that was a part of the package's git repo.

To make us less worried about the state of possibly-inconsistent installations, it would be really useful to have an option (or config setting) to have godep go set $GOPATH variable to only the godep workspace. Currently, it appends to the existing $GOPATH, which is what we want to avoid by using godep (overriding the path entirely for every project means we get completely repeatable builds across machines/envs, which is super enticing to us).

We emulate this behavior via:

GOPATH=$(godep path) go build

Hi, I've tried godep, but without success. When I run godep save, it fails:

$ godep save
godep: unrecognized import path "_/home/nono/dev/ADP/api"
godep: error loading packages
$ pwd
/home/nono/dev/ADP/api
$ go version
go version go1.1.2 linux/386

Not sure what I should do to fix this error.

One drawback of godep's current default behavior is that repos using it cease to be 'go gettable'. This is a big problem because it impacts a lot of people: not just the repo's developers but also its users.

This problem can be solved by rewriting the import paths of dependency packages so they are imported via the current repo. (This is what goven does, albeit crudely.)

I propose to add a new flag for godep save: -r, to rewrite import paths and make the repo's packages go gettable. For a project P that imports dependency D, flag -r would replace import path D with P/Godeps/_workspace/src/D.

Notes

• This is probably best done after #53 and #65.
• The rewriting will most likely be implemented as a separate step after all dependency code is copied into the current repo.
• If a dependency D's repo is also using godep to import a further dependency T as D/Godeps/_workspace/src/T, we need to undo that rewriting first so that we list both D and T directly (rewritten locally as P/.../D and P/.../T). This is only an issue when D's repo contains both packages and commands; normally there's no reason for a non-main package to use godep.
• Open question whether to keep the _workspace (and src) path element. I lean toward keeping it, mostly because the underscore causes the go tool to skip that directory when walking the filesystem, so 'go list ./...' won't list all your dependencies.

It would be convenient to have a godep get ... command that did the right thing.

$ godep get github.com/bitly/nsq/...

vs.

$ git clone [email protected]/bitly/nsq.git && cd nsq
$ godep go build ./...

Is much simpler for end users expecting "go get" like simplicity while still being able to produce reliable builds.

I 'go getted' a package and needed to fix a bug. I don't know if the pull request will be accepted. I want to vendor my version of the code for now. The tool will not let me.

For now I will need to restore the original, vendor the code, and then make my changes in the vendored version.

Would like to override that protection.

Godep's unit of composition is the repository, not the package.
This is a bit different from how most of the standard go tools
operate, and our attempt to hide this difference by using only
import paths has caused a bug or two, e.g. #27.

We fixed #27 by more consistently using the repo root when
listing and copying dependencies. We should also consider
renaming the field to help prevent further confusion and bugs.

For people who don't want to check in godep sources, it would be really convenient if godep restore had an option (or config setting) to install into the godep workspace. Currently, we run:

GOPATH=$(godep path) godep restore

to fetch the sources listed in the godep spec we check in. This (along with the next issue, which I'm gonna file shortly) would pretty much bring godep up to feature parity with bundler for us (no qualitative comparison intended 😉).

I know even less about practical bzr usage than about hg.
It shouldn't be too hard to add bzr support, just adding a new
entry alongside the ones for git and hg.

https://github.com/kr/godep/blob/82376c1c/vcs.go#L46-58
https://github.com/kr/godep/blob/82376c1c/vcs.go#L62

There are eight functions that godep uses (sort of a lot, and
it would be nice to reduce that, but that's a separate issue):
Identify, Describe, IsDirty, Create, Link, Exists, Fetch, and
Checkout. It might be tricky if we can't find bzr commands
that map closely to those functions. But we can cross that
bridge when we come to it.

In my project (https://github.com/asm-products/readraptor) I'm using Goose for migrations and need to install a binary on Heroku. I'm using:

// +build heroku

package main

import _ "bitbucket.org/liamstask/goose/cmd/goose"

godep save fails to pick up the dependency. On Heroku, install runs with godep go install -tags heroku ./...

I think godep save -tags heroku ./... would fix the issue.

Occasionally it is useful to alias the file system location dependencies are cloned under (particularly when trying to use a fork of an existing project without changing all of the import paths).

Example use case:

• You are using a library on Github and find a bug
• You fork, fix the bug, and submit a PR to the upstream
• Until the bug is merged in, you'd like to pin the revision to your fork, but maintain the same filesystem location to not break internal imports.

This is something we could support in Godep with a new, optional, key (perhaps AliasPath) that would be used as the remote and symlinked to ImportPath.

I'd be happy to code this up, but wanted to make sure this is something you'd find useful merging. Right now we are using Godep with a hack afterwards to add a new origin.

go version go1.0.2

please mention go version required on main page

I've been tracking heroku/hk lately and have had trouble with my git pull && godep go build flow. Worked with @bgentry to track it down today.

The problem seems to be that objects in Godeps/_workspace/pkg are stale but not rebuilt. Nuking that directory then running godep go build works.

Haven't dug into why yet but wanted to get an issue opened.

It's useful to be able to see differences between the saved list of deps and the installed set of deps in the workspace without having to run godep save and without thereby clobbering the saved list.

Let's consider a command godep diff:

$ godep diff
--- Godeps
+++ $GOPATH
@@ -25,7 +25,7 @@
        },
        {
            "ImportPath": "github.com/kr/fernet",
-           "Rev": "9596341a4fd02e93cd80509911ea9ed4cd84e7bf"
+           "Rev": "54c3c8fb9a0701721fceaa28780ce25ef447fd4f"
        },
        {
            "ImportPath": "github.com/kr/sshpool",

or

$ godep diff
--- Godeps
+++ $GOPATH
@@ -24,6 +24,10 @@
            "Rev": "b2f2731352d9db3b628d6ff086741de7530c10a9"
        },
        {
+           "ImportPath": "github.com/kr/fernet",
+           "Rev": "9596341a4fd02e93cd80509911ea9ed4cd84e7bf"
+       },
+       {
            "ImportPath": "github.com/kr/sshpool",
            "Rev": "f7f9e575cb90c1cb120028cc228b4e458053c227"
        },

Original report follows.

Consider adding an audit command which ensures no un-godep'd packages are involved with the current build (thy can be in workspace, but must not be part of the dependnecy graph for package being audited.

package main

import (
    "go/build"
    "flag"
    "fmt"
    "strings"
    "log"
)


var verbose= flag.Bool("v", false, "verbose output")

func init() {
    flag.Parse()
}

func main() {
    ctx := build.Default
    visited := make(map[string]bool)

    pkg, err := ctx.Import(".", ".", build.AllowBinary)
    if err != nil {
        log.Fatalf("error on import: %s", err);
    }           
    explort(ctx, pkg, visited)  
}

func explort(ctx build.Context, pkg *build.Package, visited map[string]bool) {
    for _, packageName := range pkg.Imports {
        if !visited[packageName] {
            visited[packageName] = true
            if *verbose || strings.Contains(packageName, ".") {
                fmt.Printf("%s\n", packageName)
            }
            if ! (packageName == "C") {
                child, err := ctx.Import(packageName, pkg.Dir, build.AllowBinary)
                if err != nil {
                    log.Fatalf("error on import: %s", err);
                }                   
                explort(ctx, child, visited)
            }
        }
    }
}

Will trace out imported stuff recursively.

I expect godep restore to restore into my GOPATH, not create a src folder in my current directory. (tested on OSX)

I have a test repo at https://github.com/viblo/dep-library1

$ cd $GOPATH
$ go get github.com/viblo/dep-library1
$ cd src/github.com/viblo/dep-library1
$ godep restore
$ tree src
src
└── github.com
    └── BurntSushi
        └── toml

Here is a workflow:

% go get -t ./...
% godep restore ./...

Now imagine that a package A declares a package B as dependency in the pinned version, but in master A no longer depends on B. When I run go get, I won't download the package B, because I don't need it, but after restoring my dependencies I start needing package B, which is not available.

This actually happens with tsuru and docker: docker master doesn't depend on github.com/dotcloud/tar anymore, but our pinned version does (see this build failure). So we need to manually download github.com/dotcloud/tar.

Is it an issue or am I missing something?

When I try to execute the command godep save on a proyect that is set up with SVN, the message that is printed on console is :

godep: Subversion is unsupported: C:\GOPATH\src\gomad
godep: error loading packages

Although the message is clear and said that SVN is unsupported, I want knowing wheather is a caracterist that is going to be at the future or the tool is not developed for SVN.

By analogy with 'go get'.

Running godep save with no flags should keep already-saved dependencies as they are, and only add missing packages. Running godep save -u will then be necessary to update versions.

bells@bells-desktop:$ godep get github.com/bitly/nsq
package github.com/bitly/nsq
imports github.com/bitly/nsq
imports github.com/bitly/nsq: no buildable Go source files in /home/bells/go/src/github.com/bitly/nsq
godep: exit status 1
bells@bells-desktop:$
bells@bells-desktop:$
bells@bells-desktop:$ godep get github.com/bitly/nsq
godep: no buildable Go source files in /home/bells/go/src/github.com/bitly/nsq
bells@bells-desktop:~$

why?

thank you!

Consider making the version string in Godeps easier to consume by machine (for example, a shell script). Strip off the go version and darwin/amd64, leaving only go1.1.2. This can be used, for example, to download or select the specified go compiler.

In #35, @mreiferson writes:

Relatedly, I'm curious to hear your thoughts on "versioning" of godep itself. Its been fantastic that as it evolved it has maintained backwards compatibility and I think the change as you've implemented here continues that. Still, it might be important to begin to lay the groundwork so something can be embedded in the manifest identifying compatibility, making it a little easier to manage the possibility of needing to make breaking changes.

My code is on BitBucket and if I add godep path to my bashrc like below, I then get prompted for my BitBucket password. If I remove it from my Bashrc things work as expected.

export GOPATH=~/Code/gocode
export GOPATH=`godep path`:$GOPATH

If you have previously used godep restore your git repositories will be in a detached head state, but godep tries to run git pull --ff-only, but this fails with

From github.com:Foo/Bar
   19a3d36..c056ec2  master     -> origin/master
You are not currently on a branch. Please specify which
branch you want to merge with. See git-pull(1) for details.

    git pull <remote> <branch>

Furthermore if you try and work with

export GOPATH=$(godep path)
godep restore

Nothing really works because the files under _workspace directory are not in their original git repositories so when godep tries:

git checkout 19a3d368eacde07ff631578ca7de3ec1d5e3a2cd
fatal: reference is not a tree: 19a3d368eacde07ff631578ca7de3ec1d5e3a2cd

These seem pretty fundamental so I don't really understand how this hasn't come up before - perhaps I'm missing something, but I don't see how restore can work unless you have synchronised your repositories manually...

Firts at all, the version of GOLANG that I'm using is 1.2.1(go1.2.1.linux-amd64.tar.gz ).

Second, godep was downloaded from https://github.com/kr/godep the same say of this post(09/03/2014).

My GOLANG tree is :

$GOPATH / bin
--------------------/ godep
-------------/ pkg
-------------/ src
--------------------/ github.com / aresetian / server /
--------------------------------------------------------------/ main.go

My problem :

when I write "godep save" from the place where is main.go the message on console is :
godep: directory "XYXYXYXYXY" is not using a known version control system
godep: error loading packages

XYXYXYXYXY : path where is $GOPATH

I have read some post; Add a -extonly option to "godep save" #48 ,http://mmcgrana.github.io/2012/09/getting-started-with-go-on-heroku.html, but there aren't one that can help me to solve this problem.

Reproduce

go get github.com/josharian/godepbug
cd $GOPATH/src/github.com/josharian/godepbug
go build ./...  # sanity check
godep save ./...  # initial save succeeds
git add .
git commit -m "Vendor"
godep save ./...  # save after commit fails

Result

godep: dirty working tree: $GOPATH/src/github.com/josharian/godepbug
godep: error loading dependencies

Diagnosis

github.com/josharian/godepbug contains a package (subpkg) that references another package in the same repo. (This is not uncommon -- one package has an interface, another package has a struct that satisfies it.) When running godep save ./..., the act of updating Godeps for one of the packages puts the local tree in a dirty state, which causes the godep save for the other package to fail.

Running just godep save is not an alternative, since it does not necessarily pick up all dependencies from all packages.

A fix to #53 will likely fix this as well, since it will likely involve changing Godeps after all preliminary work is done. Wanted to file this as well, though, so that it was on the radar.

Workaround

rm -rf Godeps
git add --all .
git commit -m "Unvendor"
godep save ./...
git add .
git commit -m "Vendor"
git rebase -i HEAD^2

My intention is to make godep use its -copy behavior by default,
and leave the original behavior under -copy=false.

This won't really add or remove any functionality, just change the
default choice.

From #17:

If you have dependencies that are also not gettable (but in the local workspace),
you get the same "unrecognized import path" error for those dependencies.

This happens because package vcs uses the online server to figure out
which VCS to use. We could consider letting these packages be vendored
with revision "unknown".

How to reproduce (you will need git, hg and bzr):

% go get -d -t github.com/globocom/tsuru/provision/docker
% cd $GOPATH/src/github.com/dotcloud/docker
% git checkout v0.6.5
% cd -
% godep save -copy github.com/globocom/tsuru/provision/docker
panic: runtime error: index out of range

goroutine 1 [running]:
runtime.panic(0x2ca760, 0x6522f7)
    /Users/f/lib/go/src/pkg/runtime/panic.c:266 +0xb6
main.copySrc(0xc21013fd60, 0x11, 0xc210039600, 0xc21013fd60, 0x11)
    /Users/f/gocode/src/github.com/kr/godep/save.go:133 +0x488
main.runSave(0x650720, 0xc21000a030, 0x1, 0x1)
    /Users/f/gocode/src/github.com/kr/godep/save.go:86 +0x7da
main.main()
    /Users/f/gocode/src/github.com/kr/godep/main.go:80 +0x302

goroutine 4 [finalizer wait]:
runtime.park(0x18b40, 0x655bf8, 0x654168)
    /Users/f/lib/go/src/pkg/runtime/proc.c:1342 +0x66
runfinq()
    /Users/f/lib/go/src/pkg/runtime/mgc0.c:2276 +0x84
runtime.goexit()
    /Users/f/lib/go/src/pkg/runtime/proc.c:1394
...

Full output: https://gist.github.com/fsouza/7236354

This is the only Tsuru package that fails. Info about my environment:

% go version
go version devel +938b64b0f608 Wed Oct 30 09:39:20 2013 -0700 darwin/amd64
f% uname -a
Darwin Franciscos-MacBook-Pro.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64

I'm using the latest godep (as of 14-11-2013). It looks like it should support bzr but it doesn't work for me.

My test file:

krzysztofs-mbp:test_godep kkowalczyk$ cat main.go

package main

import (
    "fmt"
    "launchpad.net/goamz/aws"
)

func main() {
    fmt.Printf("Test for godep\n")
    _ = aws.Auth{"foo", "bar"}
}

krzysztofs-mbp:test_godep kkowalczyk$ godep save -copy=false
godep: Unsupported sandbox VCS: Bazaar
godep: Instead, run: godep save -copy .

godep save works, but I would really like the -copy=false option to work.

Can the problem be related to handling sub-packages (i.e. launchpad.net/goamz/aws is a sub-package of launchpad.net/goamz) ?

Similar to how git operates correctly in any subdirectory in the repo,
godep should also do The Right Thing when run in a subdirectory.

Presumably this means checking parent directories recursively until
we find a Godeps file or reach the root.

If the package has a dependency not listed in Godeps, the go tool process run by godep go will use whatever version happens to be installed in the outer workspace, which could be different on various machines or at various times.

Command godep go should check for this and raise an error.

For things like gox (see #34), it would be really nice to be able to have the binaries available on the workspace (that definitely does interfere with vendored operation). I'm sure there must be an easy way to install the binaries from things, the way go get does, but I haven't been able to discover how, yet.

Here's what I tried:

• GOPATH=$(godep path) godep go build github.com/mitchellh/gox - this puts a gox binary in the project root
• GOPATH=$(godep path) godep go install github.com/mitchellh/gox - this has no observable effect (no binary being installed anywhere, it seems).

After running godep save in the app/tmp folder to update new dependencies, I noticed godep added the entire app folder to the Godeps folder.

Could this have something to do with the fact that main is not at the root of the project?

Errors of the form

inconsistent definition for type ssh.CryptoConfig during import

occasionally happen when using godep.

Speculate the cause is switching between two sets of dependencies,
with one intermediate package S sharing a common version but using
two different versions of transitive dependency T:

Package P's Godeps:

P
1 S
2 T

Package Q's Godeps:

Q
1 S
3 T

where S depends on T, and P and Q may or may not directly depend on T.
Running godep go build in P causes T to build with the current timestamp.
Subsequently running godep go build in Q does not rebuild S, but is using
a different version of T. So Q and S see different, incompatible versions
of the symbols defined in T, and the program cannot link.

It seems that for godep save [-copy] to do its thing, the import path of the local package must be accessible by go get on the network, even though it exists in the local workspace. Is this intended behavior?

$ godep save -copy
godep: unrecognized import path "j4k.co/app/term4k"
godep: error loading packages

$ echo $GOPATH
/Users/jamesgray/gocode

$ pwd
/Users/jamesgray/gocode/src/j4k.co/app/term4k

This came up during @fdr's testing.

For the pull, edit, update dependency, godep save, push cycle,
a godep restore command would make things much easier.