Hacker News Reader

Comment by raingrove | Hacker News Reader

Because we love choice?

Godep wants you to touch your GOPATH. For example, `godep save` saves revisions of packages currently installed in your GOPATH and `godep restore` downloads packages into your current GOPATH. If you don't want to pollute global GOPATH, you will have to change it. This works for some people, doesn't for others.

Goop doesn't want you to worry about GOPATH. Goop also encourages you to explicitly state which packages you are using in the Goopfile, rather than "capturing" what is already in use.

View on HN

Godep has been pretty composable in my experience. I use Godep in a makefile to build, and it does everything in a constructed GOPATH as well.

  GOPATH := ${CURDIR}/build
  
  build:
    @env GOPATH="${GOPATH}" godep restore
    @test -d "${GOPATH}/src/github.com/user/repo" || ln -s "${CURDIR}" "${GOPATH}/src/github.com/user/repo"
    @env GOPATH="${GOPATH}" go install github.com/user/repo

I do like the look of Goop's dep format file though. The Godeps file is pretty ugly in comparison.

It is worth noting that godep recently added an import path rewrite option, which removes the need to manipulate your workspace's packages or even run the dependency tool in order to `go get` or build your code.

https://github.com/tools/godep/commit/983ff9241cead0f7e6ad0a...

Edit: Though, perhaps the final solution could be cleaner with a vendoring tool written from the ground up with the purpose of import path rewriting.

From what I can tell, goop has the same GOPATH issues as godep, but godep allows you to address it in different ways. save/restore is one way, and there is also the proxy to the go tool `godep go` which looks to be the goop approach.

Thanks for answering my questions in paragraphs 2 and 3. Not sure how paragraph 1 was useful.

I see godep as a swiss knife of tools, and different people use godep in completely different ways (which has its advantages and disadvantages). Personally, the only godep commands I use are:

  rm ./Godeps && godep save --copy=false      # Save current dep versions
  rm -rf $TMPDIR/godep && godep go build/test # build/test using saved dep versions

It's not really clear from the documentation/README how this works under the hood, so for now I have to just go by what you're saying here until I have time to actually take a closer look.

First off, I will say that I'm not a great fan of godep, so I'm not looking to advocate for it. That said:

> Godep wants you to mangle with your GOPATH. For example, `godep save` saves revisions of packages currently installed in your GOPATH and `godep restore` downloads packages into your current GOPATH. If you don't have to pollute global GOPATH, you will have to change it. This works for some people, doesn't for others.

Your $GOPATH is a list of directories, not a single directory. This is almost never useful in practice (most people should just use a single directory as their GOPATH). However, for what you're trying to do here, that would be far simpler than introducing a third-party tool, especially one that requires adoption from all project contributors.

> Goop doesn't want you to worry about GOPATH.

The $GOPATH is technically not part of the Go language (spec), but it is a language-wide idiom respected by all build tools. I'd be very nervous about a project that eschews such firm idioms in favor of its own inventions.

Goop still sets and uses GOPATH (whenever you `goop exec` or `goop go` for example), it just eliminates the need for you to set it per directory/project that you are working on.

I think there is a little bit of confusion in this discussion about changing GOPATH as in changing the value of the env var vs changing the content of the directory tree pointed by the env var.

> Your $GOPATH is a list of directories, not a single directory. This is almost never useful in practice (most people should just use a single directory as their GOPATH).

I disagree. I use and recommend a 2 directory GOPATH setup. The first path being the one where all 'go get' packages are installed and the second being where you put your packages. I've found keeping these separated makes long term management easier.

Why? "my code" is in $GOPATH/src/github.com/natefinch/ ... all code that is not "my code" is in other directories. Why bother having to switch over to some other gopath to get there?

Go import directories, are, by definition, unique. My work code is under github.com/juju/. Why should I put labix.org/v2/mgo under some other root path? They're unique directories either way.

Reply on news.ycombinator.com