Looks fantastic, thanks for this!
Goop – Dependency Manager for Go
21–30 of 46 posts
Re: Goop – Dependency Manager for Go
#22Earlier quoted context omitted.
Or, in what ways does the design philosophy here differ enough to warrant a separate project instead of making PRs to godep?
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…
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
Re: Goop – Dependency Manager for Go
#23Hope Gwyneth Paltrow doesn't get upset about the name. http://www.goop.com
Re: Goop – Dependency Manager for Go
#24Earlier quoted context omitted.
Sill like to know what Erlang's dependency management is :)
there is no import, what you are calling is either there because you included the path to the beam file when you are starting up the VM or it is not there and calling the function returns an error. all of the libs are organized to the module:function structure and you cannot chain.
That sounds dreadful.
Re: Goop – Dependency Manager for Go
#25I'm curious why so many of these Go dependency managers are popping up. Doesn't go get download all dependencies automatically? Why are these third-party dependency managers necessary?
Re: Goop – Dependency Manager for Go
#26I'm curious why so many of these Go dependency managers are popping up. Doesn't go get download all dependencies automatically? Why are these third-party dependency managers necessary?
Because 'go get' does not allow you to point to a particular revision. It downloads the latest / HEAD commit for that dependency and sticks it into ${GOPATH}. These dependency managers are all aiming to fix that problem, and some of them, I believe, transitively.
Re: Goop – Dependency Manager for Go
#27I'm curious why so many of these Go dependency managers are popping up. Doesn't go get download all dependencies automatically? Why are these third-party dependency managers necessary?
Because 'go get' does not allow you to point to a particular revision. It downloads the latest / HEAD commit for that dependency and sticks it into ${GOPATH}. These dependency managers are all aiming to fix that problem, and some of them, I believe, transitively.
Why would you want to use an older version of a package? Just to ensure compatibility by using a version known to work?
Re: Goop – Dependency Manager for Go
#28I've been doing basically the same thing by creating src/ and pkg/ directories and using this alias: go='GOPATH=`pwd`:$GOPATH go'
In this case, try to run a `go get`, it will install everything into your current directory's bin/ directory.
go get still works but it uses the src/ ... AFAIK there's no bin/ with go...
Re: Goop – Dependency Manager for Go
#29Earlier quoted context omitted.
Because 'go get' does not allow you to point to a particular revision. It downloads the latest / HEAD commit for that dependency and sticks it into ${GOPATH}. These dependency managers are all aiming to fix that problem, and some of them, I believe, transitively.
Why would you want to use an older version of a package? Just to ensure compatibility by using a version known to work?
Yes
Re: Goop – Dependency Manager for Go
#30Earlier quoted context omitted.
Because 'go get' does not allow you to point to a particular revision. It downloads the latest / HEAD commit for that dependency and sticks it into ${GOPATH}. These dependency managers are all aiming to fix that problem, and some of them, I believe, transitively.
Why would you want to use an older version of a package? Just to ensure compatibility by using a version known to work?
Because of the way go get works when people are sharing packages. As an example:
Package author blub shares his package with the world, or his team, which depends on github.com/blab/blab. Unfortunately a week later github.com/blab/blab goes through a major rewrite, and breaks blub, but people doing go get blub get the new blab, and their build is broken, so they start complaining to the blub author.
Solutions to this:
Expect blab never to make a breaking change (somewhat optimistic)
Vendor a specific version of blab into blub and update manually
Explicitly specify a version of blab to use with a dependency tool
Each approach has some drawbacks.