Multiple versions of the same module

[shamwow]

Is there a good reason why go mod doesn't support having multiple versions of the same module (at least as an opt in feature)?

What I'm trying to achieve:

I depend on module [email protected] and [email protected] but module [email protected] depends on [email protected]. I'd like to retain the above dependencies above rather than flattening them and bumping module b to v1.1.0 for my application code.

[email protected] should be backwards compatible with [email protected] but this depends on module developers following semantic versioning. It would be much less error prone if each module was able to use its own set of dependencies.

If go mod would write a /vendor directory for each module, it seems like the above would be possible. Common dependencies along a chain could be pruned and included in the top most /vendor directory to help reduce binary blot.

Examples (-> indicates a dependency, M is the root project):

If the dependencies were:
M -> [email protected]
M -> [email protected]
[email protected] -> [email protected]

The topmost vendor dir would look like:
vendor/[email protected]
vendor/[email protected]/vendor
vendor/[email protected]/vendor/[email protected]
vendor/[email protected]

If the dependencies were:
M -> [email protected]
M -> [email protected]
[email protected] -> [email protected]

The topmost vendor dir would look like:
vendor/[email protected]
vendor/[email protected]

If the dependencies were:
M -> [email protected]
M -> [email protected]
[email protected] -> [email protected]
[email protected] -> [email protected]
[email protected] -> [email protected]

The topmost vendor dir would look like:
vendor/[email protected]
vendor/[email protected]
vendor/[email protected]/vendor/[email protected]
vendor/[email protected]/vendor/[email protected]
vendor/[email protected]/vendor/[email protected]/vendor/[email protected]

Note that as described, a type defined in vendor/[email protected]/vendor/[email protected]/vendor/[email protected] would not be compatible with the same type in vendor/[email protected] even though they are from the same version of the same package.

[davecheney]

This sounds like a recipe for making binaries even larger than they are today.

Also, what happen is if you have two minor versions of the same dependency that try to register themselves as http handlers, db drivers, or try to redirect stdout to themselves?

[mvdan]

What @davecheney said. Also, the packages somemodule/[email protected] and somemodule/[email protected] have the same import path, somemodule/pkg, so it's impossible for the Go build system to differentiate them. The only way is to use different major versions, so that the second is somemodule/v2/pkg.

So, if you want to use multiple versions of one module at once, the answer is to use different major versions. Otherwise, simply using the latest version within one major version should work, as per semantic versioning. If a module out there pushed v1.1.0 with backwards incompatible changes, file a bug or fork the repository as needed.

[shamwow]

@mvdan I'm not trying to use two minor versions in the same package but rather allow individual modules to specify their own minor version.

@davecheney's point about dependencies that try to register themselves as http handlers or db drivers is a good argument against this though.

[emman27]

Hi @davecheney @mvdan, I'm curious as to your thoughts regarding dependencies that are pre-v1. I've encountered the exact same problem with a pre-v1 package which made incompatible changes (which by semver specification, is perfectly okay).

So
root -> modA -> github.com/apache/[email protected]
root -> modB -> github.com/apache/[email protected]

Seems like a valid dependency chain based on semver, but there's no way for me to resolve this?

[davecheney]

@emman27 this issue is closed. Please move the discussion to another forum, https://github.com/golang/go/wiki#the-go-community