0

I am working on a new Golang application which involves some proprietary code and also includes some open sources packages. The code will be part of an enterprise GitHub repository.

We don't plan to keep using the latest versions of the open source packages and would want to keep a stable version of the packages. In this context what is the best way to organize the code? From what I have read so far the best way to put the opensource packages into the Vendors directory.

In any case, a clear project layout is something we want to have in the beginning to keep things simple in the long run.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
kshirol
  • 41
  • 1
  • 5

1 Answers1

1

If you are using a version of Go < 1.11, you can take a look at dep for dependency management :

  • a dep init will generate the layout (see Creating a New Project)
  • a Gopkg.lock file will handle specific revisions for each dependency, thus ensuring the stability of your build (instead of having different developers using different versions of the same dependency, depending on when they go get that dependency).

However, if you are using a version of Go >= 1.11, as @oren points out in the comments section (credits to him), you'd probably want to use Go modules instead, as it is now introduced in the Go tool chain.

norbjd
  • 10,166
  • 4
  • 45
  • 80
  • 2
    Don't use `dep`. dep is not gonna be in the main tool chain, use `go module` instead, especially for new projects. – oren Dec 15 '18 at 19:02
  • @oren I missed that; guess it's time to upgrade my Go version to 1.11 :) I've updated the answer with your suggestion, thanks for the input. – norbjd Dec 15 '18 at 22:24
  • cool, one more thing though, for ‘go 1.10’ I would use ‘vgo’ https://github.com/golang/vgo/blob/master/README.md. And if I start a new project I don’t see any reason not to upgrade to go 1.11. ‘dep’ is having issues which ’vgo/go module’ fix. The right way as I see it (especially to new project) is to just use vgo – oren Dec 15 '18 at 22:36
  • @oren modules don't work well yet - managing transitive dependencies with modules is near to impossible (unless you have control over depended code bases as well), while `dep` easily allows to do anything one could imagine. – zerkms Dec 15 '18 at 22:53
  • @zerkms Isn’t ‘semantic import versioning’ reducing the ‘transitive dependencies conflict’, when two major versions are required in the same build? I probably not thinking right on **managing** transitive dependancies. If you have an example I’ll like to know. Thanks – oren Dec 15 '18 at 23:42
  • @oren " Isn’t ‘semantic import versioning’ reducing the ‘transitive dependencies conflict" --- nope. This is a long read with a lot of other links, but the problem is not trivial at all https://github.com/gofrs/uuid/issues/61. In short: it's simple to get everything working with `dep` and it's really hard to guarantee your library would work everywhere with modules. – zerkms Dec 16 '18 at 03:10