7 ms·

Goop – Dependency Manager for Go

71 points by alixaxel 12y ago

aosmith 12y ago
I've been doing basically the same thing by creating src/ and pkg/ directories and using this alias: go='GOPATH=`pwd`:$GOPATH go'
- dengnan 12y ago
  In this case, try to run a `go get`, it will install everything into your current directory's bin/ directory.
  - aosmith 12y ago
    go get still works but it uses the src/ ... AFAIK there's no bin/ with go...
dz0ny 12y ago
set -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.
- rem7 12y ago
  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 https://github.com/crowdmob/goamz.git master --squash
jameskilton 12y ago
What does this offer that godep doesn't?
- shurcooL 12y ago
  Or, in what ways does the design philosophy here differ enough to warrant a separate project instead of making PRs to godep?
  - raingrove 12y ago
    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.
    - chimeracoder 12y ago
      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.
      - raingrove 12y ago
        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.
leccine 12y ago
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.
- macrael 12y ago
  What does Erlang do?
  - leccine 12y ago
    Gets you downvotes on HN.
    - macrael 12y ago
      Sill like to know what Erlang's dependency management is :)
      - leccine 12y ago
        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.
        ossreality 12y ago
        That sounds dreadful.
alecthomas 12y ago
Config file is nicer than godep; easily generated with a bit of shell. Quite nice.
imslavko 12y ago
It 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.
- raingrove 12y ago
  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`.
  - grey-area 12y ago
    until there is a standard versioning scheme (there isn't much you can do with git hashes) Couldn't you use tags for versioning? Often people use tag v1.1.1 etc?
    - cstrahan 12y ago
      See: "and a standard dependency manifest file that every go project adopts" You need some way to create a complete dependency graph for a given project. If your project has a list of its immediate dependencies, but those dependencies in turn require specific versions of other packages, how do know what those versions are? You need some consistent way of getting this metadata. There are a couple solutions, but a few that come to mind: each project stores their deps metadata in a consistent location in their repo, or there's some central package repo (a la RubyGems) where such metadata can be queried. For any solution to work, all of your dependencies (both direct and indirect) need to opt in to the same metadata scheme, or the system falls apart. Unfortunately, there isn't any consensus in the Go community on how to fix this. This is what the parent meant by "there isn't much you can do with git hashes."
- munificent 12y ago
  From the looks of it, it just has a lockfile. None of the version resolution that makes bundler interesting.
vmiroshnikov 12y ago
If someone looks for an alternative, consider this kit: https://github.com/pote/gvp https://github.com/pote/gvp - virtualenv in go's world https://github.com/pote/gpm https://github.com/pote/gpm - pip in go's world
dkulchenko 12y ago
Looks fantastic, thanks for this!
sswaner 12y ago
Hope Gwyneth Paltrow doesn't get upset about the name. http://www.goop.com http://www.goop.com
dead10ck 12y ago
I'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?
- collinvandyck76 12y ago
  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.
  - dead10ck 12y ago
    Why would you want to use an older version of a package? Just to ensure compatibility by using a version known to work?
    - forsaken 12y ago
      Yes
    - grey-area 12y ago
      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.
  - jzelinskie 12y ago
    For git (and probably others) It actually looks for a "go1" tag, and if not there it uses the head of master. I honestly don't care for all these version managers. If I didn't trust the author of whatever library I'm pulling in to keep their API stable, then I wouldn't use that library or I'd preemptively fork. This is actually a language convention and if more people were familiar with it, there would be even less issues (though I haven't ever had any personally). If you're interested in helping the community familiarize themselves with Go's language conventions, I made a package[0] that developers should read after going through the Go Tour. It's meant to teach best practices and conventions for library design in Go. [0] https://github.com/jzelinskie/conventions https://github.com/jzelinskie/conventions
kylered 12y ago
In case anyone is interested, we open sourced this one about a year ago: https://github.com/VividCortex/johnny-deps https://github.com/VividCortex/johnny-deps

71 points by alixaxel 12y ago

I've been doing basically the same thing by creating src/ and pkg/ directories and using this alias: go='GOPATH=`pwd`:$GOPATH go'

dengnan 12y ago
In this case, try to run a `go get`, it will install everything into your current directory's bin/ directory.
- aosmith 12y ago
  go get still works but it uses the src/ ... AFAIK there's no bin/ with go...

dz0ny 12y ago

set -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.

rem7 12y ago
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 https://github.com/crowdmob/goamz.git master --squash

jameskilton 12y ago

What does this offer that godep doesn't?

shurcooL 12y ago
Or, in what ways does the design philosophy here differ enough to warrant a separate project instead of making PRs to godep?
- raingrove 12y ago
  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.
  - chimeracoder 12y ago
    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.
    - raingrove 12y ago
      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.

leccine 12y ago

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.

macrael 12y ago
What does Erlang do?
- leccine 12y ago
  Gets you downvotes on HN.
  - macrael 12y ago
    Sill like to know what Erlang's dependency management is :)
    - leccine 12y ago
      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.
      - ossreality 12y ago
        That sounds dreadful.

alecthomas 12y ago

Config file is nicer than godep; easily generated with a bit of shell. Quite nice.

imslavko 12y ago

It 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.

raingrove 12y ago
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`.
- grey-area 12y ago
  until there is a standard versioning scheme (there isn't much you can do with git hashes) Couldn't you use tags for versioning? Often people use tag v1.1.1 etc?
  - cstrahan 12y ago
    See: "and a standard dependency manifest file that every go project adopts" You need some way to create a complete dependency graph for a given project. If your project has a list of its immediate dependencies, but those dependencies in turn require specific versions of other packages, how do know what those versions are? You need some consistent way of getting this metadata. There are a couple solutions, but a few that come to mind: each project stores their deps metadata in a consistent location in their repo, or there's some central package repo (a la RubyGems) where such metadata can be queried. For any solution to work, all of your dependencies (both direct and indirect) need to opt in to the same metadata scheme, or the system falls apart. Unfortunately, there isn't any consensus in the Go community on how to fix this. This is what the parent meant by "there isn't much you can do with git hashes."
munificent 12y ago
From the looks of it, it just has a lockfile. None of the version resolution that makes bundler interesting.

vmiroshnikov 12y ago

If someone looks for an alternative, consider this kit: https://github.com/pote/gvp https://github.com/pote/gvp - virtualenv in go's world https://github.com/pote/gpm https://github.com/pote/gpm - pip in go's world

dkulchenko 12y ago

Looks fantastic, thanks for this!

sswaner 12y ago

Hope Gwyneth Paltrow doesn't get upset about the name. http://www.goop.com http://www.goop.com

dead10ck 12y ago

I'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?

collinvandyck76 12y ago
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.
- dead10ck 12y ago
  Why would you want to use an older version of a package? Just to ensure compatibility by using a version known to work?
  - forsaken 12y ago
    Yes
  - grey-area 12y ago
    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.
- jzelinskie 12y ago
  For git (and probably others) It actually looks for a "go1" tag, and if not there it uses the head of master. I honestly don't care for all these version managers. If I didn't trust the author of whatever library I'm pulling in to keep their API stable, then I wouldn't use that library or I'd preemptively fork. This is actually a language convention and if more people were familiar with it, there would be even less issues (though I haven't ever had any personally). If you're interested in helping the community familiarize themselves with Go's language conventions, I made a package[0] that developers should read after going through the Go Tour. It's meant to teach best practices and conventions for library design in Go. [0] https://github.com/jzelinskie/conventions https://github.com/jzelinskie/conventions

kylered 12y ago

In case anyone is interested, we open sourced this one about a year ago: https://github.com/VividCortex/johnny-deps https://github.com/VividCortex/johnny-deps