Re:Go vgo: Semantic Versioning and Human Error
by dbaupp on Monday May 21, 2018 @09:58PM
(#17123257)
> Go packages can have side effects. For example a global map, background goroutines, shared connection pools, etc. Including multiple versions of the same package would not work for these cases.
Yes, that's a problem too, but there's a lot of packages which don't have side-effects (I'd expect more of the latter, in fact).
Your point that there needs to be control over packages that should be singletons and/or "public dependencies" is a fair one (it's something that has been considered for cargo for a while, but I'm not sure it's been implemented yet), but allowing multiple versions for packages without side-effects is a strict improvement over the abstraction-breaking "one version globally" for every package.
> If I have a struct defined in a package version 1 that gets an extra field in version 2 how can I possibly reuse that struct between packages.
You can't: they're different types. The underlying assumption of having multiple versions of a package is that imports have unique (name, version), not just name, meaning "a" v1 and "a" v2 are treated as completely different packages, just like "a" v1 and "b" v2.
Yes, that's a problem too, but there's a lot of packages which don't have side-effects (I'd expect more of the latter, in fact).
Your point that there needs to be control over packages that should be singletons and/or "public dependencies" is a fair one (it's something that has been considered for cargo for a while, but I'm not sure it's been implemented yet), but allowing multiple versions for packages without side-effects is a strict improvement over the abstraction-breaking "one version globally" for every package.
> If I have a struct defined in a package version 1 that gets an extra field in version 2 how can I possibly reuse that struct between packages.
You can't: they're different types. The underlying assumption of having multiple versions of a package is that imports have unique (name, version), not just name, meaning "a" v1 and "a" v2 are treated as completely different packages, just like "a" v1 and "b" v2.