cmd/go: vendored dependencies lack language version annotations #36876
Comments
If anyone upgrades to a new Go version, and updates their |
@mvdan, ideally, a user changing the language version in their own |
Hm, maybe I misunderstood. I thought re-running |
Re-running To minimize churn in |
(The |
FWIW, I would suggest thinking a bit more about the possible virtues of your approach 2., including as things evolve in the future (e.g., perhaps another bit of information might get added to go.mod in the future). Also, some small-ish chance that storing the current go.mod files might be a stepping stone towards storing old go.mod files as well, which might end up enabling more cmd/go functionality when in vendor mode (e.g., #30240 (comment) and next couple comments there), though I think storing the old |
I'd lean toward option (1). Seems simpler.
|
Seems like the |
@bcmills what are the next steps here? |
Since there haven't been any breaking language changes in Go 1.15, this doesn't need to be a release-blocker. (I do still plan to add the annotation, but I'm not sure whether it will make 1.15.) |
Change https://golang.org/cl/244078 mentions this issue: |
…e globally Previously, this cache was a member of the (ephemeral) modload.loader struct. However, the Go language version for a given module version does not vary based on the build list, the set of loaded packages, the build tags in use, the meaning of the "all" pattern, or anything else that can be configured for an instance of the package loader. The map containing that information is therefore not appropriate as a field of the (configurable, package-list-dependent) loader struct. The Go language version mapping could, in theory, be read from the go.mod file in the module cache (or replacement directory) every time it is needed: this map is just a cache, and as such it belongs alongside the other caches and indexes in the modload package, which are currently found in modfile.go. We may want to do the same sort of global caching for the mapping from each module.Version to its list of direct requirements (which are similarly idempotent), but for now that is left for a future change. For #36460 For #36876 Change-Id: I90ac176ffea97f30c47d6540c3dfb874dc9cfa4f Reviewed-on: https://go-review.googlesource.com/c/go/+/244078 Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
Change https://golang.org/cl/303229 mentions this issue: |
…explicit 'go' directives Fixes #45109 Updates #44976 Updates #36876 Change-Id: Icb00f8b6e0d4e076d82da1697e7058b9e7603916 Reviewed-on: https://go-review.googlesource.com/c/go/+/303229 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
In writing #36875, I realized that we will have a bit of a problem with vendored dependencies if and when we start making incompatible changes to the language.
Specifically, the
vendor
directory is a flattened package tree, and it does not includego.mod
files unless the vendored package dependencies happen to include a package at the root of the vendored module. Many modules (such asgolang.org/x/tools
) don't even have an importable package at the root, let alone one that someone would want to import.Unfortunately, the
go.mod
files are currently the only place where we record the language version to use for those dependencies. (I don't know what language version we end up using for-mod=vendor
builds today, but I don't see how it could possibly be the correct one in general.)I can think of two possible fixes:
Extend the
##
annotation comments that we added for #33848 so that, for any module that provides one or more packages, we annotate thego
version (if any) found in the dependency's originalgo.mod
file. (Fortunately, we intentionally designed that part of the format to tolerate the addition of new annotations.)For example:
Explicitly copy in the
go.mod
files for each module that provides one or more packages, even if there is no corresponding package in that part of thevendor
tree.I have a slight preference for approach (1) but don't feel strongly about it.
(CC @ianlancetaylor @griesemer @jayconrod @matloob @mvdan)
The text was updated successfully, but these errors were encountered: