3 ms·

> If a module specifies go 1.17 or higher in its go.mod file, its transitive requirements are now loaded lazily, avoiding the need to download or read go.mod fi

> If a module specifies go 1.17 or higher in its go.mod file, its transitive requirements are now loaded lazily, avoiding the need to download or read go.mod files for otherwise-irrelevant dependencies. To support lazy loading, in Go 1.17 modules the go command maintains explicit requirements in the go.mod file for every dependency that provides any package transitively imported by any package or test within the module. See the design document for more detail. Wait, does this mean we can import things that themselves import kubernetes without also having to include this huge list of overrides [0] due to the huge list of v0.0.0 imports that k8s then overrides? Or is that going to take other changes... (like fixing whatever makes k8s import + override v0.0.0) 0: https://github.com/replicatedhq/kots/blob/v1.47.0/go.mod#L112-L144 https://github.com/replicatedhq/kots/blob/v1.47.0/go.mod#L11... 1: https://github.com/kubernetes/kubernetes/blob/v1.21.2/go.mod#L110-L137 https://github.com/kubernetes/kubernetes/blob/v1.21.2/go.mod...

LukeShu 5y ago
> like fixing whatever makes k8s import + override v0.0.0 What needs fixing is the kubernetes.git release process. kubernetes.git/go.mod "overrides" v0.0.0 not with another version (as you do), but with a local directory, because the sources-of-truth for each of those are the kubernetes.git/staging/XXX/ directories. Because of this, if you're working in kubernetes.git the version number never actually matters, so they just leave it with a dummy v0.0.0. But it does matter if you want to import kubernetes.git! If you have nested Go modules in one repo like that, the thing to do to keep your importers happy is that whenever you do a release, you `go mod edit -require=NESTED_MODULE@VERSION` to bump the version number to the one you're about to release. This is what we do in Telepresence[1], if only we could get the Kubernetes folks to do it too... [1]: https://github.com/telepresenceio/telepresence/blob/v2.3.4/build-aux/main.mk#L102 https://github.com/telepresenceio/telepresence/blob/v2.3.4/b...

LukeShu 5y ago

> like fixing whatever makes k8s import + override v0.0.0 What needs fixing is the kubernetes.git release process. kubernetes.git/go.mod "overrides" v0.0.0 not with another version (as you do), but with a local directory, because the sources-of-truth for each of those are the kubernetes.git/staging/XXX/ directories. Because of this, if you're working in kubernetes.git the version number never actually matters, so they just leave it with a dummy v0.0.0. But it does matter if you want to import kubernetes.git! If you have nested Go modules in one repo like that, the thing to do to keep your importers happy is that whenever you do a release, you `go mod edit -require=NESTED_MODULE@VERSION` to bump the version number to the one you're about to release. This is what we do in Telepresence[1], if only we could get the Kubernetes folks to do it too... [1]: https://github.com/telepresenceio/telepresence/blob/v2.3.4/build-aux/main.mk#L102 https://github.com/telepresenceio/telepresence/blob/v2.3.4/b...