I have this problem:
- Module A imports module X v0.1.0
- Module B imports module X v0.2.0
- I import both A and B in my project.
Golang picks out X v0.2.0 and calls it good. But it is not good. v0.1 and v0.2 are different enough that A breaks and my project doesn't compile.
What options do I have to fix this?
The offical go stance seems to be "developers of X were doing it wrong and should've released a major version after breaking changes". But that doesn't help the current situation.
I can't find discussions of practical solutions.
Further information
- The above is a simplification, A and B have a couple more dependencies that also depend on X.
- This project needs to be maintainable by a group of people. So updating A and B to new versions is ideally straightforwards.
- This is security-critical code so subtle bugs from mismatched dependencies are a concern.
Things I've tried:
- Forking A and X, changing the import paths throughout, and updating A's
go.mod
. It works but makes updates to those modules slow and error prone. - Copy and pasting the required code out of A and X to avoid importing it. Also slow and error prone.
- Did a deep dive into creative applications of
go mod vendor
, but couldn't find a solution.
github.com/allegro/bigcache
andgithub.com/allegro/bigcache/v2
. Using Go interfaces I could switch - via a runtime config - between either version (asv2
was sporadically crashing). Depending on the coverage of the API you are using, an interface may help you do something similar with a "forked" version. – Habitedv0
major version, according to semver, is for initial development. Anything may change at any time. The public API should not be considered stable. Instead it's modules that import libraries inv0
that do so at their own risk. – Quire