Hi, Maxime Devos <maximede...@telenet.be> writes:
>> > have uses outside go-ethereum, so they can be re-used as dependencies of >> > new go packages, so over time, having to define many new packages when >> > importing >> > a go application should become less and less of a problem. >> > >> > (About version pinning: I'm ignoring version incompatibilities here. I >> > don't know >> > how much of a problem that is in practice ...) >> >> i'm not a go expert at all, but i think it's a rather frequent >> situation in go land to move a dependency one git commit ahead, only >> to pick up a bugfix that has just been pushed into its repo. > > ... unless you meant this here? But this seems to imply that version > incompatibilities typically don't happen (otherwise just picking up > a bugfix with a single commit doesn't seem plausible), so we can > typically just use the latest version of the go module in guix, no? A clarification: a canonical Go module version is supposed to follow semantic versioning guidelines [0], so anything except a major version bump is supposed to be backwards-compatible. This is further supported by major version suffixes [1], which requires that "[s]tarting with major version 2, module paths must have a major version suffix like /v2 that maches the major version. For example, if a module has the path example.com/mod at v1.0.0, it must have the path example.com/mod/v2 at version v2.0.0." Because each Guix package only represents one module path, and that module path is used in the name of the package, we *should* be able to update to (and use) any newer minor versions of a module with no issues. This doesn't address packages without any canonical versions, of course... [0] https://golang.org/ref/mod#versions [1] https://golang.org/ref/mod#major-version-suffixes -- Sarah