9 ms·

Just wondering, does Go finally has a package manager with proper versioning of modules? Edit: Somebody is heavily downvoting me on every reply, I would love t

by bonn1 12y ago

Just wondering, does Go finally has a package manager with proper versioning of modules? Edit: Somebody is heavily downvoting me on every reply, I would love to know why. I like Go and want to get into it since a few months but the missing package manager held me off. So what is wrong about my question?

Skunkleton 12y ago
I don't have a ton of experience with go, just some one off internal tools development, only a few dependencies. That said, I chose to manage my dependencies manually by making a fork of the relevant repositories. Yeah, it would have been nice if the higher order dependencies were automatically resolved, but the whole thing went smoothly, and felt familiar since it had nothing to do with Go at all. Maybe the take away is that a language agnostic dependency manager is what would best benefit Go?
- EugeneOZ 12y ago
  And how you follow minor version updates with your forked repos?
bbrazil 12y ago
The closest is godep, which lets you take snapshots. We're having lots of fun with this with Prometheus, quite a bit of work is ongoing to get it into Debian due to this for example.
- bonn1 12y ago
  And do these package managers provide a full ecosystem where all Go libraries/modules are available like e.g. npm does?
  - campoy 12y ago
    All Go packages can be found on godoc.org Installed with "go get" And if you want to vendor the dependencies use godep.
    - bonn1 12y ago
      Thanks. And how can I define the version of the module which should be imported?
      - bbrazil 12y ago
        https://github.com/tools/godep/blob/master/Readme.md https://github.com/tools/godep/blob/master/Readme.md explains it. It's not really a package manager, though you can get some of the same results. It's more pulling in exact build dependencies.
      - deleted 12y ago
        [deleted]
      - grey-area 12y ago
        You can't. You are expected to vendor for dependable builds. This has upsides and downsides. It does completely sidestep version dependencies hell and encourages you to think carefully about which dependencies you package. It does that by making you manually responsible for keeping dependencies up to date if you distribute other people's code with your own. So, in answer to your original question, no go doesn't finally have a package manager with proper versioning (at least no official one). In practice, this is not as big an issue as you might think if you come from a language with such a package manager. In practice, I haven't really found it as much of a burden as I thought I might.
        NateDad 12y ago
        Yes, you can. The URL is the version. If you want a different version, you need a different url. For example, when I released v1 of my package "lumberjack" you imported it with import "github.com/natefinch/lumberjack" When I updated it to v2, I had to change the url. Luckily there's http://gopkg.in http://gopkg.in to make this easy, so for v2 it's import "gopkg.in/natefinch/lumberjack.v2" Note that the above url actually redirects to the v2 branch of the same github repo.
        12y ago
ansible 12y ago
We prefer to use version control, and vendor libraries in our project instead. This is language-agnostic, and allows us to have repeatable builds without extra tools. I've written up a tutorial about it using git-subtree: https://github.com/jamesgraves/example-go-app https://github.com/jamesgraves/example-go-app
- StevePerkins 12y ago
  Does this not wholly preclude the possibility of vendors shipping a library without source?
  - ansible 12y ago
    We normally exclude the entire pkg directory, but in that case you could just add selected files from there.
NateDad 12y ago
You really don't need a package manager for Go. Honestly, the main reason you need them for node, python, etc is because you're deploying source code to your production environment. You don't do that with Go. You deploy a binary, which has everything wrapped up in itself. Think of it as a self-contained virtualenv that requires zero effort on your part :) In Go, code is packaged via source control repos. If you want a different version, you need a different repo. There are some tools to mitigate this, so that you can get away with a different branch per version (see http://gopkg.in http://gopkg.in), which can make it a little nicer for the maintainer to deal with multiple branches. To the consumer, it still looks like a different repo (i.e. every different version is a different URL to a repo). Note that because Go is a compiled language, the only time versioning comes into play is a development time. As long as your developers are using the right version, you never have to worry about versions during deployment. Now, if you're concerned that your project depends on code repos from external sources, then there are several tools that can insulate you from third parties doing stupid stuff. The most complete and best one is called godep, which basically has two modes - reliable and paranoid. The reliable mode insulates you from changes made to a repo you depend on by recording the exact VCS revision your project is using and always checks out that commit. That way, if an upstream repo checks in a breaking change, it won't affect you (and you control when you update to newer commits in that repo). Paranoid mode actually copies all the code from your dependencies into your own repo. This insulates you from upstream repos getting deleted. And of course, this gives you the ability to test out upstream changes before integrating them into your project. The tool makes it easy to copy all of your dependencies at once with a single command, so it's not a huge hassle to do (which it would be if you had to do it by hand).
- eddieroger 12y ago
  I'm on board with this answer, and it makes sense to me, but it's competing in my head with the idea of always being able to do a clean build from master that could deploy whenever. Let's say you have a catastrophic failure and lose your binary repo and need to rebuild (and your backups, etc - it's an example) - if your dependencies have changed in the meanwhile, you can't redeploy to where you were. Obviously that scenario should be well prevented, but that doesn't feel like a legitimate excuse to not have some safeguard in place to make sure your build environment doesn't change on you.
ptio 12y ago
https://github.com/pote/gpm https://github.com/pote/gpm
erikb 12y ago
As far as I know the system is different. You pull your requirements from repos recursively. It's maybe slower but in exchange it's more lightweight. For most cases it shouldn't be a kill reason. So what's the problem with that? PS: I'm no go developer either. But the way it pulls in requirements was a nice idea in my eyes.
SEJeff 12y ago
Your questions was serious and not a troll, so I upvoted it. It seems like vendoring really is the "accepted upstream method" for solving this problem. Even the Fedora packagers for golang apps are asking to relax the requirement on unbundling vendored things for golang as there is no sane way to handle versions other than git commit hashes.

by bonn1 12y ago

Skunkleton 12y ago

I don't have a ton of experience with go, just some one off internal tools development, only a few dependencies. That said, I chose to manage my dependencies manually by making a fork of the relevant repositories. Yeah, it would have been nice if the higher order dependencies were automatically resolved, but the whole thing went smoothly, and felt familiar since it had nothing to do with Go at all. Maybe the take away is that a language agnostic dependency manager is what would best benefit Go?

EugeneOZ 12y ago
And how you follow minor version updates with your forked repos?

bbrazil 12y ago

The closest is godep, which lets you take snapshots. We're having lots of fun with this with Prometheus, quite a bit of work is ongoing to get it into Debian due to this for example.

bonn1 12y ago
And do these package managers provide a full ecosystem where all Go libraries/modules are available like e.g. npm does?
- campoy 12y ago
  All Go packages can be found on godoc.org Installed with "go get" And if you want to vendor the dependencies use godep.
  - bonn1 12y ago
    Thanks. And how can I define the version of the module which should be imported?
    - bbrazil 12y ago
      https://github.com/tools/godep/blob/master/Readme.md https://github.com/tools/godep/blob/master/Readme.md explains it. It's not really a package manager, though you can get some of the same results. It's more pulling in exact build dependencies.
    - deleted 12y ago
      [deleted]
    - grey-area 12y ago
      You can't. You are expected to vendor for dependable builds. This has upsides and downsides. It does completely sidestep version dependencies hell and encourages you to think carefully about which dependencies you package. It does that by making you manually responsible for keeping dependencies up to date if you distribute other people's code with your own. So, in answer to your original question, no go doesn't finally have a package manager with proper versioning (at least no official one). In practice, this is not as big an issue as you might think if you come from a language with such a package manager. In practice, I haven't really found it as much of a burden as I thought I might.
      - NateDad 12y ago
        Yes, you can. The URL is the version. If you want a different version, you need a different url. For example, when I released v1 of my package "lumberjack" you imported it with import "github.com/natefinch/lumberjack" When I updated it to v2, I had to change the url. Luckily there's http://gopkg.in http://gopkg.in to make this easy, so for v2 it's import "gopkg.in/natefinch/lumberjack.v2" Note that the above url actually redirects to the v2 branch of the same github repo.
        12y ago

ansible 12y ago

We prefer to use version control, and vendor libraries in our project instead. This is language-agnostic, and allows us to have repeatable builds without extra tools. I've written up a tutorial about it using git-subtree: https://github.com/jamesgraves/example-go-app https://github.com/jamesgraves/example-go-app

StevePerkins 12y ago
Does this not wholly preclude the possibility of vendors shipping a library without source?
- ansible 12y ago
  We normally exclude the entire pkg directory, but in that case you could just add selected files from there.

NateDad 12y ago

You really don't need a package manager for Go. Honestly, the main reason you need them for node, python, etc is because you're deploying source code to your production environment. You don't do that with Go. You deploy a binary, which has everything wrapped up in itself. Think of it as a self-contained virtualenv that requires zero effort on your part :) In Go, code is packaged via source control repos. If you want a different version, you need a different repo. There are some tools to mitigate this, so that you can get away with a different branch per version (see http://gopkg.in http://gopkg.in), which can make it a little nicer for the maintainer to deal with multiple branches. To the consumer, it still looks like a different repo (i.e. every different version is a different URL to a repo). Note that because Go is a compiled language, the only time versioning comes into play is a development time. As long as your developers are using the right version, you never have to worry about versions during deployment. Now, if you're concerned that your project depends on code repos from external sources, then there are several tools that can insulate you from third parties doing stupid stuff. The most complete and best one is called godep, which basically has two modes - reliable and paranoid. The reliable mode insulates you from changes made to a repo you depend on by recording the exact VCS revision your project is using and always checks out that commit. That way, if an upstream repo checks in a breaking change, it won't affect you (and you control when you update to newer commits in that repo). Paranoid mode actually copies all the code from your dependencies into your own repo. This insulates you from upstream repos getting deleted. And of course, this gives you the ability to test out upstream changes before integrating them into your project. The tool makes it easy to copy all of your dependencies at once with a single command, so it's not a huge hassle to do (which it would be if you had to do it by hand).

eddieroger 12y ago
I'm on board with this answer, and it makes sense to me, but it's competing in my head with the idea of always being able to do a clean build from master that could deploy whenever. Let's say you have a catastrophic failure and lose your binary repo and need to rebuild (and your backups, etc - it's an example) - if your dependencies have changed in the meanwhile, you can't redeploy to where you were. Obviously that scenario should be well prevented, but that doesn't feel like a legitimate excuse to not have some safeguard in place to make sure your build environment doesn't change on you.

ptio 12y ago

https://github.com/pote/gpm https://github.com/pote/gpm

erikb 12y ago

As far as I know the system is different. You pull your requirements from repos recursively. It's maybe slower but in exchange it's more lightweight. For most cases it shouldn't be a kill reason. So what's the problem with that? PS: I'm no go developer either. But the way it pulls in requirements was a nice idea in my eyes.

SEJeff 12y ago

Your questions was serious and not a troll, so I upvoted it. It seems like vendoring really is the "accepted upstream method" for solving this problem. Even the Fedora packagers for golang apps are asking to relax the requirement on unbundling vendored things for golang as there is no sane way to handle versions other than git commit hashes.