0

My go project consists of many components. Every component has its own vendor directory, which is populated by the dep. Because components have similar dependencies, there is a huge duplication in vendor directories. Additionally, vendors are quite big: ~20MB.
My idea is to reduce the size of the repository by defining common vendor, on the top of the project. project vendor |--component1 |----main.go |----vendor |--component2 |----main.go |----vendor

Every component needs to define only dependencies specific to him. To not provision common dependencies on every dep ensure executed on the component level, we can specify which packages should be ignored in Gopkg.toml file:

ignored = ["github.com/aszecowka/calc"]

Question: Does anyone use this approach? Any alternatives?

Update Context: In my company we are investigating monorepo approach, we try to consolidate different go projects, but we end up with a really huge repository - mostly because of many vendors directories

Adam Szecowka
  • 675
  • 3
  • 8
  • 20
  • 2
    Everyone uses this approach, because [multiple vendor directories cause type conflicts](https://stackoverflow.com/questions/38091816/packages-type-cannot-be-used-as-the-vendored-packages-type). There should only ever be one vendor directory per main package. In other words, component1 and component2 shouldn't have a vendor directory to begin with. It is up to the main package to assemble a set of vendored packages that works with all of its dependencies. – Peter Jun 29 '18 at 08:20
  • 2
    You should possibly employ what is called "dependency flattening"—that is, you have a single top-level `vendor` directory and has all the dependencies, including transitional, there. See [this](https://www.google.com/search?lang=en&q=golang+flatten+dependencies). – kostix Jun 29 '18 at 09:43
  • @kostix My components are developed by separate teams. All components have dependencies to k8s, but they also involve different domains. I don't want to have one vendor, because it will become enormous. Additionally, component1 can require the same dependency as a component2, but in a different version. – Adam Szecowka Jun 29 '18 at 11:26
  • @Peter thanks for your response. In my example, component1 and component2 are separate apps, both have `main.go` file (I updated the description of my problem) and own vendors. My question is: if both components use some common libraries, can we extract those overlapping dependencies and put it in vendor directory on the level above? In my company we are investigating monorepo approach, we try to consolidate different go projects, but we end up with a really huge repository - mostly because of many vendors directories. – Adam Szecowka Jun 29 '18 at 11:50
  • @AdamSzecowka no, for the same reason, as Peter stated: "There should only ever be one vendor directory per main package." – Adrian Jun 29 '18 at 13:09
  • The really interesting discussion can be found here: https://github.com/golang/dep/issues/985 _yes, flattening vendor directories up to the single, topmost level is foundational to dep's design. nested vendor directories can cause numerous problems, and eliminating them was an intentional choice. changing that design is not something we can do._ And: _dep is not primarily designed for use in monorepos right now_ – Adam Szecowka Jun 30 '18 at 08:10

0 Answers0