4 ms·

Go packages can have side effects. For example a global map, background goroutines, shared connection pools, etc. Including multiple versions of the same packag

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. Actually this isn't really a go specific thing. 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.

kasey_junk 8y ago
Because every other dependency management system has realized that nothing about the version number actually tells you anything about compatibility & so they don’t even try. That vgo encodes semver as sone sort of contract system is crazy pants on a whole new level.
- cdoxsey 8y ago
  Sure they do. What if I do want to share the same struct between packages? I need both of my dependencies to share the same version of their dependant packages. I don't think I understand what you're getting at. In ruby I can say I depend on a version > 1.2.0 and some other project could use my package and use version 1.2.1, thus altering my dependency. Bundler lets me do that because it makes assumptions about what version numbers mean. The lock file makes sure this only changes when I want it too, but semver is an integral part of the system
- dbaupp 8y ago
  Many package managers interpret semver in a similarly mechanical way, e.g. npm, bundler, cargo (and, I think, elm-package, and I'm sure others too), but they choose different versions based on that information.
  - mzl 8y ago
    And crucially, in these systems you are given an escape hatch (declaring versions that are not ok), which vgo does not support.
    - hectormalot 8y ago
      I think vgo allows you exclude specific versions in go.mod. It only works for specific versions, not ranges though
      - mzl 8y ago
        There are exclusions, but they are only available for the current module: > Exclusions only apply to builds of the current module. If the current module were required by a larger build, the exclusions would not apply. https://research.swtch.com/vgo-tour https://research.swtch.com/vgo-tour
dbaupp 8y ago
> 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.

kasey_junk 8y ago

Because every other dependency management system has realized that nothing about the version number actually tells you anything about compatibility & so they don’t even try. That vgo encodes semver as sone sort of contract system is crazy pants on a whole new level.

cdoxsey 8y ago
Sure they do. What if I do want to share the same struct between packages? I need both of my dependencies to share the same version of their dependant packages. I don't think I understand what you're getting at. In ruby I can say I depend on a version > 1.2.0 and some other project could use my package and use version 1.2.1, thus altering my dependency. Bundler lets me do that because it makes assumptions about what version numbers mean. The lock file makes sure this only changes when I want it too, but semver is an integral part of the system
dbaupp 8y ago
Many package managers interpret semver in a similarly mechanical way, e.g. npm, bundler, cargo (and, I think, elm-package, and I'm sure others too), but they choose different versions based on that information.
- mzl 8y ago
  And crucially, in these systems you are given an escape hatch (declaring versions that are not ok), which vgo does not support.
  - hectormalot 8y ago
    I think vgo allows you exclude specific versions in go.mod. It only works for specific versions, not ranges though
    - mzl 8y ago
      There are exclusions, but they are only available for the current module: > Exclusions only apply to builds of the current module. If the current module were required by a larger build, the exclusions would not apply. https://research.swtch.com/vgo-tour https://research.swtch.com/vgo-tour

dbaupp 8y ago

> 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.