Two version of same dependency - lower version getting ignored

Question

I have a project in which two dependencies uses different version of same library. For instance, my project has dependency A and dependency B. A and B, both uses a common library/dependency X, but of different versions. A has v1 version of X and B has v2 version of X. So now when I add A & B as dependencies in my project, there are 2 versions of X in my project's go.sum.

I was expecting, the respective versions will be referred at run time by A and B. But it is not the case. Somehow when I run tests on my project, the A is using v2 of X, ideally it should use v1 (because in go.mod of A, explicitly specified/added v1). So it breaks the execution,because there are lot differences in v1 and v2 of X.

So in my project, how can I explicitly specify that to use v1 of X by A and use v2 by B? Is there such provision in go modules?

Hoppe

If what you call "v1" and "v2" are really different major versions in the SemVer sense (i.e. incompatible): See icza's answer. If not: You are doomed as a package can exist in a Go binary only in (at most) 1 major version (= same import path). – Russ

Answer 1

Your B package must import X with a /v2 suffix.

Go Wiki: Modules: Semantic Import versioning:

Recall semver requires a major version change when a v1 or higher package makes a backwards incompatible change. The result of following both the import compatibility rule and semver is called Semantic Import Versioning, where the major version is included in the import path — this ensures the import path changes any time the major version increments due to a break in compatibility.

As a result of Semantic Import Versioning, code opting in to Go modules must comply with these rules:

• If the module is version v2 or higher, the major version of the module must be included as a /vN at the end of the module paths used in go.mod files (e.g., module github.com/my/mod/v2, require github.com/my/mod/v2 v2.0.0) and in the package import path (e.g., import "github.com/my/mod/v2/mypkg").

This version suffix in the import path will make them 2 "different" packages. If A and B would use the same major version of X, then there would be no 2 versions of it, the higher version would be chosen ("minimal version selection" algorithm). For details, see Version Selection.

Practitioner

The dependency, which causing issue, X, does not have any versioning/packaging. That dependency is github.com/pierrec/lz4. In this case, how to handle it? – Hoppe

@Hoppe In that case you're in trouble. Go modules requires the packages to have semver2 versioning to work properly. If the package does not follow this, you have to create copies of the package manually with the commits you wish to use, and use these "snapshots". – Practitioner

Yea, i guess you are right, thanks @Practitioner for the help. Technically your answer is correct if used packages in the dependency. – Hoppe