Go dependency management

In Go, if you are referencing another package, for example. something on GitHub, then Go always gets the latest version from the master branch. Although this is great for development, I think this is a problem in production: thus, the assembly is not reproducible.

So, what is the correct way in Go to fix the dependency version and how to handle it efficiently?

A friend pointed me to godep , and it seems fine, but I wanted to know what alternatives exist, and what is good / bad in godep?

+6
source share
2 answers

June 2015 Update: First Provider Support Moving Into Go 1.5!
See c / 10923 / :

When GO15VENDOREXPERIMENT=1 is in the environment, this CL changes the resolution of the import paths as suggested by the Go 1.5 provider:

  • If the source directory d/vendor exists, then when compiling the source file inside the subtree root in d , import "p" interpreted as import "d/vendor/p" if it exists.
  • When there are several possible permissions, the most specific (longest) path wins.
  • A short form should always be used: the import path cannot contain " /vendor/ " explicitly.
  • Comment import is ignored in vendor packages.

Update March 2015: the go team is thinking about defining a go dependency management system integrated into the language: discussion in this thread .

We think it's time to start solving the problem of addiction and the provider, especially before there are too many conflicting tools and fragment the best practices in the Go ecosystem, making the tools unnecessarily complicated. It would be nice if the community could converge in a standard way to the supplier.

Our suggestion is that the Go project,

  • officially recommends selling to the directory, with the ability to overwrite imports (not GOPATH modifications) as a canonical way of binding dependencies.
  • defines a common configuration file format for dependencies and provider
  • does not change the code on cmd/go in Go 1.5. External tools such as " godep " or " nut " will implement 1) and 2). We can overestimate, including such a tool in Go 1.6 +.

One of the potential drawbacks of godep is that you can no longer use "go build" or "go test" directly.
You need to precede these commands with godep (or type godep save ).

An alternative is glide , which is still compatible with classic go commands.

  • GOPATH Project Management
  • Simple dependency management
  • Version Control Pack Support
  • Support for alias packages (e.g. for working with github forks)
  • Remove the need for β€œsuppliers” or import import reports.
  • Work with all go tools

More generally, the article β€œ Know your guarantees, Go edition ” is interesting:

Its also a deliberate choice when the Go authors decided not to implement the function when they felt that the compromises were not good.

One of the low-level reasons they made this choice is to avoid slow compilation and bloated binaries (which are two sides of the same coin).
Remember that packages depend on other packages . Thus, Foo may depend on Bar 2.1. Foo can also depend on Baz , which in turn depends on Bar 1.9 and the tree. Thus, this would mean compiling and linking multiple copies of almost identical code.

Depending on several versions of the same package, it also means knowing which version alone is being invoked, resulting in a mess of dependencies seeping into the source code.

This leads us to the higher-level reasoning behind the Go platform based on this feature: they did not have a logical solution that they considered acceptable. This does not mean that they do not understand the problem; it is that at the moment there is no solution that they like. Therefore, they do not choose any function over regressive .

+9
source

You handle dependencies, for example, you handle dependencies in other languages: the provider. There is no Nexus for Go that makes vendors, so just copy the external libraries to the "vendor" folder, there are tools here. Personally, I found that all this "fixed version" panic is a little exaggerated, since it works very well.

You can take a look at http://labix.org/gopkg.in and look for golang nuts for dependency management. I think there is even a whole mailing list dedicated to this.

+1
source

Source: https://habr.com/ru/post/978822/


All Articles