2

I am new to go. I am working on a go project that cannot be in a single git repository. The exact case is that I have to make public a library I am developing and I at the same time have a private project that depends on it. I would assume that there are many other scenarios that such need could arise.

It seems the existing go dependency management is designed around the concept that components or other 3rd party dependencies will be moving in significant well-defined steps with switching to different repo locations.

In my case, I would like to grow my public and my private part of the code together, where I would like to have a setup that allows having a significant number of breaking changes. Where I can submit in my public library without breaking the build of the existing private project. And later moving my private dependent project to such version with the according fixes.

Creating different repo address for almost every change in my public library to achieve this seems overkill and expensive to do.

Any advice?

gsf
  • 6,612
  • 7
  • 35
  • 64
  • Update Feb. 2018: there is no the official project vgo: See https://stackoverflow.com/a/48914523/6309 – VonC Feb 21 '18 at 20:10

1 Answers1

1

Since 1.5 Go has built in support for vendoring (enabled by default since 1.6).

Your best bet is vendoring your packages as git submodules under the vendor/ folder in your private package and manually upgrading them.

There are a lot of tools that simplifies that, I've personally used manul which is rather simple.

https://github.com/golang/go/wiki/PackageManagementTools is a good read.

OneOfOne
  • 95,033
  • 20
  • 184
  • 185
  • 1
    More surveys of tools: in https://blog.filippo.io/analyzing-go-vendoring-with-bigquery/ the author of gvt measures usage, and https://forum.golangbridge.org/t/the-best-dependency-manager/1281 discusses. – twotwotwo Jul 05 '16 at 23:48
  • But I'm a BORG drone from the future :( – OneOfOne Jul 06 '16 at 03:53