CODEWITHSUNDEEP
godependency-managementgo-modulesvendoring
Sebi2020
Sebi2020

Reputation: 2150

How to build project whose dependencies depend on another version of a project dependency

Imagine you have a project which requires two modules A and B. I will call the project module P. Let's say that P requires A v1.0.0, B v1.1.0 and that A requires B v1.0.0. Furthermore B did not adhered semantic versioning rules thus the version change from v1.0.0 -> v1.1.0 introduced a breaking API change. So P only builds with v1.1.0 and A only builds with v1.0.0.

Dependency graph:

P -> A (v1.0.0) -> B(v1.0.0)
P -> B (v1.1.0)

Is there any way to build this project with different versions. I heared about vendoring but I'm not sure if this would cause the dependency to use a different B module version.

And if it could provide a solution for the conflicting package versions, does the go tool recognize modules using vendoring if the dependencies do not include a vendor folder (some people say, you should not upload the vendor folder) in their git repository (In this case module A does not ship with a vendor folder, but the developer called go mod vendor locally), does the go get command respect vendor folders of dependencies (or can it detect that the module used vendoring without an upstream vendor folder)?

Upvotes: 2

Views: 1337

Answers (1)

Eli Bendersky
Eli Bendersky

Reputation: 273456

This seems like a conflict the module system cannot resolve. Since Go uses semantic versioning it will try to get B v1.1.0 to resolve both dependencies and then the build will break if A cannot work with B 1.1.0.

The best way to resolve it is to fix B by not breaking the API in a non-major version.

Lacking that, you could fork B into a separate module (with a different module name from the original B) and use an old version in A. Create BFORK=Bv1.0.0, and then you'll have:

P -> B (v1.0.0)
A -> BFORK vX.X.X

Upvotes: 5

Related Questions