Multiple versions of the same module #31578
Comments
|
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? |
|
What @davecheney said. Also, the packages 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 |
|
@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. |
|
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 Seems like a valid dependency chain based on semver, but there's no way for me to resolve this? |
|
@emman27 this issue is closed. Please move the discussion to another forum, https://github.com/golang/go/wiki#the-go-community |
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 a@v1.0.0 and b@v1.0.0 but module a@v1.0.0 depends on b@v1.1.0. 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.
b@v1.1.0 should be backwards compatible with b@v1.0.0 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 modwould write a/vendordirectory 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/vendordirectory to help reduce binary blot.Examples (
->indicates a dependency,Mis the root project):Note that as described, a type defined in
vendor/a@v1.0.0/vendor/b@v1.0.0/vendor/c@v1.0.1would not be compatible with the same type invendor/c@v1.0.1even though they are from the same version of the same package.The text was updated successfully, but these errors were encountered: