Goop for teh rescue! The only trouble I had with go is the dependency handling. I wish people realize how Erlang's way of dealing with this is superior.
What does Erlang do?
Gets you downvotes on HN.
Goop – Dependency Manager for Go
11–20 of 46 posts
Re: Goop – Dependency Manager for Go
#12If someone looks for an alternative, consider this kit:
https://github.com/pote/gvp - virtualenv in go's world
https://github.com/pote/gpm - pip in go's world
Re: Goop – Dependency Manager for Go
#13It says it is inspired by Bundler but in what ways? I am curious as I didn't use much of neither bundler nor goop but I have heard the constraints resolution lays in the heart of bundler.
You are right. Unfortunately, constraints resolution isn't something that can be implemented in a practical manner until there is a standard versioning scheme (there isn't much you can do with git hashes) and a standard dependency manifest file that every go project adopts.
Goop has `Goopfile.lock` and `goop exec`, inspired by Bundler's `Gemfile.lock` and `bundle exec`.
Re: Goop – Dependency Manager for Go
#14It says it is inspired by Bundler but in what ways? I am curious as I didn't use much of neither bundler nor goop but I have heard the constraints resolution lays in the heart of bundler.
From the looks of it, it just has a lockfile. None of the version resolution that makes bundler interesting.
Re: Goop – Dependency Manager for Go
#15set -x GOPATH (PWD)/.vendor set -x GOBIN (PWD)/.vendor/bin And committing stuff in git when it matters. gvm is also nice for testing stuff with different versions of go.
I also setup my path per project. And vendor all my deps under _vendor
And for getting libraries instead of doing go get I use git subtrees like so:
git subtree add --prefix _vendor/src/github.com/crowdmob/goamz https://github.com/crowdmob/goamz.git master --squash
Re: Goop – Dependency Manager for Go
#16What does this offer that godep doesn't?
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 state which packages you are using in the Goopfile, rather than "capturing" what is already in use.
Re: Goop – Dependency Manager for Go
#17Re: Goop – Dependency Manager for Go
#18Earlier 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…
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.
Re: Goop – Dependency Manager for Go
#19Earlier quoted context omitted.
Gets you downvotes on HN.
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.
Re: Goop – Dependency Manager for Go
#20Earlier quoted context omitted.
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…
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 y…
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.