2

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)?

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
Sebi2020
  • 1,966
  • 1
  • 23
  • 40
  • 1
    You will have to import B in P with some V2 prefix. Read this related thread https://stackoverflow.com/questions/57602028/two-version-of-same-dependency-lower-version-getting-ignored. – Nikhil Apr 11 '20 at 15:10

1 Answers1

5

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
Eli Bendersky
  • 263,248
  • 89
  • 350
  • 412
  • Does that mean the only solution is to manually rewrite the code of **all** my dependencies (if they all use different incompatible versions of dependencies I use in my own module) to be compatible with the new API? – Sebi2020 Apr 11 '20 at 14:06
  • @Sebi2020 if you fork it you could just rewrite the imports. I updated the answer with more details – Eli Bendersky Apr 11 '20 at 16:49