aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/go/internal/modfetch/coderepo.go
AgeCommit message (Collapse)Author
2022-03-03[release-branch.go1.16] cmd/go: avoid +incompatible major versions if a ↵Bryan C. Mills
go.mod file exists in a subdirectory for that version Previous versions of the 'go' command would reject a pseudo-version passed to 'go get' if that pseudo-version had a mismatched major version and lacked a "+incompatible" suffix. However, they would erroneously accept a version *with* a "+incompatible" suffix even if the repo contained a vN/go.mod file for the same major version, and would generate a "+incompatible" pseudo-version or version if the user requested a tag, branch, or commit hash. This change uniformly rejects "vN.…" without "+incompatible", and also avoids resolving to "vN.…+incompatible", when vN/go.mod exists. To maintain compatibility with existing go.mod files, it still accepts "vN.…+incompatible" if the version is requested explicitly as such and the repo root lacks a go.mod file. Fixes #51331 Updates #51324 Updates #36438 Change-Id: I2b16150c73fc2abe4d0a1cd34cb1600635db7139 Reviewed-on: https://go-review.googlesource.com/c/go/+/387675 Trust: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> (cherry picked from commit 5a9fc946b42cc987db41eabcfcbaffd2fb310d94) Reviewed-on: https://go-review.googlesource.com/c/go/+/387923 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
2022-02-07[release-branch.go1.16] cmd/go/internal/modfetch: do not short-circuit ↵Bryan C. Mills
canonical versions Since at least CL 121857, the conversion logic in (*modfetch).codeRepo.Stat has had a short-circuit to use the version requested by the caller if it successfully resolves and is already canonical. However, we should not use that version if it refers to a branch instead of a tag, because branches (unlike tags) usually do not refer to a single, stable release: a branch named "v1.0.0" may be for the development of the v1.0.0 release, or for the development of patches based on v1.0.0, but only one commit (perhaps at the end of that branch — but possibly not even written yet!) can be that specific version. We already have some logic to prefer tags that are semver-equivalent to the version requested by the caller. That more general case suffices for exact equality too — so we can eliminate the special-case, fixing the bug and (happily!) also somewhat simplifying the code. Updates #35671 Fixes #50686 Fixes CVE-2022-23773 Change-Id: I2fd290190b8a99a580deec7e26d15659b58a50b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/378400 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit fa4d9b8e2bc2612960c80474fca83a4c85a974eb) Reviewed-on: https://go-review.googlesource.com/c/go/+/382839
2020-12-09all: update to use os.ReadFile, os.WriteFile, os.CreateTemp, os.MkdirTempRuss Cox
As part of #42026, these helpers from io/ioutil were moved to os. (ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.) Update the Go tree to use the preferred names. As usual, code compiled with the Go 1.4 bootstrap toolchain and code vendored from other sources is excluded. ReadDir changes are in a separate CL, because they are not a simple search and replace. For #42026. Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3 Reviewed-on: https://go-review.googlesource.com/c/go/+/266365 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-10-20all: update references to symbols moved from io/ioutil to ioRuss Cox
The old ioutil references are still valid, but update our code to reflect best practices and get used to the new locations. Code compiled with the bootstrap toolchain (cmd/asm, cmd/dist, cmd/compile, debug/elf) must remain Go 1.4-compatible and is excluded. Also excluded vendored code. For #41190. Change-Id: I6d86f2bf7bc37a9d904b6cee3fe0c7af6d94d5b1 Reviewed-on: https://go-review.googlesource.com/c/go/+/263142 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
2020-10-20all: update references to symbols moved from os to io/fsRuss Cox
The old os references are still valid, but update our code to reflect best practices and get used to the new locations. Code compiled with the bootstrap toolchain (cmd/asm, cmd/dist, cmd/compile, debug/elf) must remain Go 1.4-compatible and is excluded. For #41190. Change-Id: I8f9526977867c10a221e2f392f78d7dec073f1bd Reviewed-on: https://go-review.googlesource.com/c/go/+/243907 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2020-10-09cmd/go: ignore retracted versions when converting revisions to versionsJay Conrod
When a module author retracts a version, the go command should act as if it doesn't exist unless it's specifically requested. When converting a revision to a version, we should ignore tags for retracted versions. For example, if the tag v1.0.0 is retracted, and branch B points to the same revision, we should convert B to a pseudo-version, not v1.0.0. Similarly, if B points to a commit after v1.0.0, we should not use v1.0.0 as the base; we can use an earlier non-retracted tag or no base. Fixes #41700 Change-Id: Ia596b05b0780e5acfe6616a04e94d24bd342fbae Reviewed-on: https://go-review.googlesource.com/c/go/+/261079 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Jay Conrod <jayconrod@google.com>
2020-03-12cmd/go: improve pseudo-version timestamp errorWalt Della
The previous "invalid pseudo-version: does not match version-control timestamp" error message used a different timestamp format than the format used in go.mod and go.sum. For cut-and-paste-ability this patch makes the two consistent. Fixes #36974 Change-Id: I21f344ab9898cc584c0bcf4a75d74275a703c650 Reviewed-on: https://go-review.googlesource.com/c/go/+/217437 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-02-24cmd/go/internal/modfetch: delete unused isVendoredPackage functionBryan C. Mills
This function is apparently unused since CL 204917. Updates #35290 Updates #37397 Change-Id: Id7f5f5d5176fdbd1c5c6227e81d0854ceafc3f12 Reviewed-on: https://go-review.googlesource.com/c/go/+/220640 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-01-08cmd/go: adjust heuristics for skipping +incompatible versionsBryan C. Mills
We know of at least one module (github.com/stripe/stripe-go) that has a run of +incompatible versions, followed by a run of versions with go.mod files, followed by another run of +incompatible versions. We want the heuristics for showing +incompatible versions to reflect the authors' current intent, and it seems clear that the current intent of the authors of that module is for users of the unversioned import path to still be on +incompatible versions. To respect that intent, we need to keep checking for +incompatible versions even after we have seen a lower major version with an explicit go.mod file. However, we still don't want to download every single version of the module to check it. A given major version should have a consistent, canonical import path, so the path (as inferred by the presence or absence of a go.mod file) should be the same for every release across that major version. To avoid unnecessary overhead — and to allow module authors to correct accidental changes to a major version's import path — we check only the most recent release of each major version. If a release accidentally changes the import path in either direction (by deleting or adding a go.mod file), it can be corrected by issuing a single subsequent release of that major version to restore the correct path. I manually verified that, with this change, github.com/stripe/stripe-go@latest reverts to v68.7.0+incompatible as it was in Go 1.13. The other regression tests for #34165 continue to pass. Updates #34165 Change-Id: I5daff3cd2123f94c7c49519babf4eecd509f169e Reviewed-on: https://go-review.googlesource.com/c/go/+/212317 Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-12-19cmd/go: relax validation for replacements for gopkg.in pathsBryan C. Mills
The 'go' command normally requires the 'go.mod' files for replacement modules to have a major version compatible with the module they are replacing. However, prior to CL 206761, the 'go' command erroneously allowed unversioned paths (which imply major version 0 or 1) to replace 'gopkg.in' paths with any major-version suffix. An analysis of proxy.golang.org suggests that these replacements, while uncommon, are not unheard-of. Rather than breaking the modules that rely on them, we will continue to allow the erroneous replacement paths for this particular pairing. Updates #34254 Change-Id: Icb4e745981803edaa96060f17a8720a058219ab1 Reviewed-on: https://go-review.googlesource.com/c/go/+/212105 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-12-06cmd/go: reduce redundancy in direct mode lookup error messagesJay Conrod
get.RepoRootForImportPath now returns errors that satisfy load.ImportPathError in cases where the import path appears in the messages. (The import path probably should appear in all errors from this function, but this CL does not change these errors). Changed modfetch.notExistError to be a wrapper (with an Unwrap method) instead of a string. This means errors.As works with notFoundError and ImportPathError. ImportMissingError no longer prints the package path if it wraps an ImportPathError. TestMissingImportErrorRepetition no longer counts the package path within a URL (like https://...?go-get=1). Fixes #35986 Change-Id: I38f795191c46d04b542c553e705f23822260c790 Reviewed-on: https://go-review.googlesource.com/c/go/+/210338 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-11-15cmd/go: allow a fork with path […]/vN to replace gopkg.in/[…].vNBryan C. Mills
Fixes #34254 Change-Id: Ib4e476d31264342538c2cf381177823183cba890 Reviewed-on: https://go-review.googlesource.com/c/go/+/206761 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-11-07cmd/go/internal/modfetch: switch to golang.org/x/mod/zipJay Conrod
zip.Create is now used to filter and translate zip files from VCS tools. zip.Unzip is now used instead of Unzip. Fixes #35290 Change-Id: I4aa41b2e96bf147c09db43d1d189b8393cafb06f Reviewed-on: https://go-review.googlesource.com/c/go/+/204917 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-11-05cmd/go/internal/modfetch: prune +incompatible versions more aggressivelyBryan C. Mills
codeRepo.Versions previously checked every possible +incompatible version for a 'go.mod' file. That is wasteful and counterproductive. It is wasteful because typically, a project will adopt modules at some major version, after which they will (be required to) use semantic import paths for future major versions. It is counterproductive because it causes an accidental '+incompatible' tag to exist, and no compatible tag can have higher semantic precedence. This change prunes out some of the +incompatible versions in codeRepo.Versions, eliminating the “wasteful” part but not all of the “counterproductive” part: the extraneous versions can still be fetched explicitly, and proxies may include them in the @v/list endpoint. Updates #34165 Updates #34189 Updates #34533 Change-Id: Ifc52c725aa396f7fde2afc727d0d5950acd06946 Reviewed-on: https://go-review.googlesource.com/c/go/+/204439 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-10-29cmd/go: delete internal packages moved to x/modJay Conrod
This change deletes several internal packages, replaces imports to them with the equivalent golang.org/x/mod packages, updates x/mod, and re-runs 'go mod vendor'. Packages are replaced as follows: cmd/go/internal/modfile → golang.org/x/mod/modfile cmd/go/internal/module → golang.org/x/mod/module cmd/go/internal/semver → golang.org/x/mod/semver cmd/go/internal/sumdb → golang.org/x/mod/sumdb cmd/go/internal/dirhash → golang.org/x/mod/sumdb/dirhash cmd/go/internal/note → golang.org/x/mod/sumdb/note cmd/go/internal/tlog → golang.org/x/mod/sumdb/tlog Updates #31761 Fixes #34924 Change-Id: Ie3bf677bb0be49af969f654a0214243a6547eb57 Reviewed-on: https://go-review.googlesource.com/c/go/+/202698 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-10-24cmd/go/internal/modfetch/codehost: remove invariantly-empty return value ↵Bryan C. Mills
from Repo.ReadZip Previously, codehost.Repo.ReadZip returned an 'actualSubdir' value that was the empty string in all current implementations. Updates #26092 Change-Id: I6708dd0f13ba88bcf1a1fb405e9d818fd6f9197e Reviewed-on: https://go-review.googlesource.com/c/go/+/203277 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-10-11cmd/go: integrate changes made in x/mod packages into internal packagesJay Conrod
This change integrates changes made to x/mod packages into our internal copies of those packages. This is the first step of a bidirectional synchronization. A follow-up change will copy changes made to the internal packages after x/mod was forked. After that, we can vendor x/mod, update imports, and delete the internal copies. The following packages are affected: * internal/module * internal/semver (no change) * internal/sumweb (renamed to internal/sumdb) * internal/dirhash * internal/note * internal/tlog Several integrated changes affect other packages: * cmd/go/internal/module.MatchPathMajor now wraps a new function, CheckPathMajor, which returns error. MatchPathMajor returns bool. This will avoid an incompatible change in the next step. * module.EncodePath renamed to EscapePath, EncodeVersion to EscapeVersion, DecodePath to UnescapePath, DecodeVersion to UnescapeVersion. * cmd/go/internal/sumweb moved to cmd/go/internal/sumdb and package renamed to sumdb. * sumdb.Client renamed to ClientOps, Conn to Client, Server to ServerOps, Paths to ServerPaths. * sumdb/encode.go and encode_test.go are not present in x/mod since they are redundant with functionality in module. Both files are deleted. * sumdb.TestServer doesn't implement sumdb.ServerOps after changes were were made to golang.org/x/mod/sumdb.ServerOps during the fork. Local changes made so tests will pass. These will be copied to x/mod in the next step. Updates #34801 Change-Id: I7e820f10ae0cdbec238e59d039e978fd1cdc7201 Reviewed-on: https://go-review.googlesource.com/c/go/+/200138 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-09-10cmd/go/internal/modfetch: report the module path for errors in ↵Bryan C. Mills
(*codeRepo).Versions Updates #34094 Change-Id: Ifd10b51c2b4ebe77c4f8f68726e411f54c13b9c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/194560 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-09-08all: fix typosAinar Garipov
Use the following (suboptimal) script to obtain a list of possible typos: #!/usr/bin/env sh set -x git ls-files |\ grep -e '\.\(c\|cc\|go\)$' |\ xargs -n 1\ awk\ '/\/\// { gsub(/.*\/\//, ""); print; } /\/\*/, /\*\// { gsub(/.*\/\*/, ""); gsub(/\*\/.*/, ""); }' |\ hunspell -d en_US -l |\ grep '^[[:upper:]]\{0,1\}[[:lower:]]\{1,\}$' |\ grep -v -e '^.\{1,4\}$' -e '^.\{16,\}$' |\ sort -f |\ uniq -c |\ awk '$1 == 1 { print $2; }' Then, go through the results manually and fix the most obvious typos in the non-vendored code. Change-Id: I3cb5830a176850e1a0584b8a40b47bde7b260eae Reviewed-on: https://go-review.googlesource.com/c/go/+/193848 Reviewed-by: Robert Griesemer <gri@golang.org>
2019-07-18cmd/go: suppress errors with '@upgrade' when the latest version is replacedBryan C. Mills
Fixes #33154 Change-Id: I5a249a77843a8bd438006af0fa1d8b4429ee25f4 Reviewed-on: https://go-review.googlesource.com/c/go/+/186617 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-07-16cmd/go: tighten the check for pseudo-version base tagsBryan C. Mills
Do not allow a pseudo-version derived from a canonical tag to refer to the same revision as the tag itself. It's unnecessary (because canonical tags already have a total ordering) and confusing (the pseudo-version appears to come after the tag, but actually refers to the exact same revision). Updates #32879 Updates #27173 Change-Id: I02befedbe89c8819bdd93e470783ce63fc813193 Reviewed-on: https://go-review.googlesource.com/c/go/+/184720 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-07-15cmd/go/internal/modfetch: always check for a go.mod file when fetching from ↵Bryan C. Mills
version control If the module path declared in the go.mod file does not match the path we are trying to resolve, a build using that module is doomed to fail. Since we know that the module path does not match in the underlying repo, we also know that the requested module does not exist at the requested version. Therefore, we should reject that version in Stat with a “not exist” error — sooner rather than later — so that modload.Query will continue to check other candidate paths (for example, with a major-version suffix added or removed). Fixes #33099 Change-Id: I43c980f78ed75fa6ace90f237cc3aad46c22d83a Reviewed-on: https://go-review.googlesource.com/c/go/+/186237 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-06-24cmd/go/internal/modfetch: treat a missing go.mod file as a “not exist” errorBryan C. Mills
If we have found a repository at the requested version but it does not contain a go.mod file in an appropriate subdirectory, then the module with the given path does not exist at that version. Therefore, we should report it with an error equivalent to os.ErrNotExist so that modload.Query will continue to check other possible module paths. Updates #27173 Change-Id: Ica73f4bb97f58e611a7f7d38183ee52fef5ee69a Reviewed-on: https://go-review.googlesource.com/c/go/+/183618 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-06-21cmd/go: validate pseudo-versions against module paths and revision metadataBryan C. Mills
Previously, most operations involving pseudo-versions allowed any arbitrary combination of version string and date, and would resolve to the underlying revision (typically a Git commit hash) as long as that revision existed. There are a number of problems with that approach: • The pseudo-version participates in minimal version selection. If its version prefix is inaccurate, the pseudo-version may appear to have higher precedence that the releases that follow it, effectively “pinning” the module to that commit. For release tags, module authors are the ones who make the decision about release tagging; they should also have control over the pseudo-version precedence within their module. • The commit date within the pseudo-version provides a total order among pseudo-versions. If it is not accurate, the pseudo-version will sort into the wrong place relative to other commits with the same version prefix. To address those problems, this change restricts the pseudo-versions that the 'go' command accepts, rendering some previously accepted-but-not-canonical versions invalid. A pseudo-version is now valid only if all of: 1. The tag from which the pseudo-version derives points to the named revision or one of its ancestors as reported by the underlying VCS tool, or the pseudo-version is not derived from any tag (that is, has a "vX.0.0-" prefix before the date string and uses the lowest major version appropriate to the module path). 2. The date string within the pseudo-version matches the UTC timestamp of the revision as reported by the underlying VCS tool. 3. The short name of the revision within the pseudo-version (such as a Git hash prefix) is the same as the short name reported by the underlying cmd/go/internal/modfetch/codehost.Repo. Specifically, if the short name is a SHA-1 prefix, it must use the same number of hex digits (12) as codehost.ShortenSHA1. 4. The pseudo-version includes a '+incompatible' suffix only if it is needed for the corresponding major version, and only if the underlying module does not have a go.mod file. We believe that all releases of the 'go' tool have generated pseudo-versions that meet these constraints. However, a few pseudo-versions edited by hand or generated by third-party tools do not. If we discover invalid-but-benign pseudo-versions in widely-used existing dependencies, we may choose to add a whitelist for those specific path/version combinations. ― To work around invalid dependencies in leaf modules, users may add a 'replace' directive from the invalid version to its valid equivalent. Note that the go command's go.mod parser automatically resolves commit hashes found in 'replace' directives to the appropriate pseudo-versions, so in most cases one can write something like: replace github.com/docker/docker v1.14.0-0.20190319215453-e7b5f7dbe98c => github.com/docker/docker e7b5f7dbe98c and then run any 'go' command (such as 'go list' or 'go mod tidy') to resolve it to an appropriate pseudo-version. Note that the invalid version will still be used in minimal version selection, so this use of 'replace' directives is an incomplete workaround. ― One of the common use cases for higher-than-tagged pseudo-versions is for projects that do parallel development on release branches. For example, if a project cuts a 'v1.2' release branch at v1.2.0, they may want future commits on the main branch to show up as pre-releases for v1.3.0 rather than for v1.2.1 — especially if v1.2.1 is already tagged on the release branch. (On the other hand, a backport of a patch to the v1.2 branch should not show up as a pre-release for v1.3.0.) To address this use-case, module authors can make use of our existing support for pseudo-versions derived from pre-release tags: if the author adds an explicit pre-release tag (such as 'v1.3.0-devel') to the first commit after the branch, then the pseudo-versions for that commit and its descendents will be derived from that tag and will sort appropriately in version selection. ― Updates #27171 Fixes #29262 Fixes #27173 Fixes #32662 Fixes #32695 Change-Id: I0d50a538b6fdb0d3080aca9c9c3df1040da1b329 Reviewed-on: https://go-review.googlesource.com/c/go/+/181881 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-05-31cmd/go/internal/modfetch: use the resolved version to search for tags in ↵Bryan C. Mills
(*codeRepo).convert Previously, we used the passed-in statVers as the basis for tag search, but it is not always valid. Instead, use info.Name, which (by precondition) must be valid. Updates #32161 Updates #27171 Change-Id: Iaecb5043bdf2fefd26fbe3f8e3714b07d22f580f Reviewed-on: https://go-review.googlesource.com/c/go/+/179857 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-04-19cmd/go/internal/modfetch: comment on known bug in isVendoredPackageBryan C. Mills
Fixes #31562 Change-Id: Ida30dd8071eccb6b490ab89a1de087038fe26796 Reviewed-on: https://go-review.googlesource.com/c/go/+/172977 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-03-08cmd/go/internal/modfetch: handle codeRoot == path for paths with ↵Bryan C. Mills
major-version suffixes Fixes #30647 Change-Id: Icbcfdb3907bc003ac17a8c7df17ecb41daf82eb4 Reviewed-on: https://go-review.googlesource.com/c/go/+/166117 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-03-02cmd/go/internal/modfetch: add missing error checksLeon Klingele
Change-Id: I51a9c06384875fbb12db0e05128f23bd23a163a1 GitHub-Last-Rev: 126452f15cbb8e06ff683dcd60e63f1925dcf8f1 GitHub-Pull-Request: golang/go#30000 Reviewed-on: https://go-review.googlesource.com/c/160424 Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-12-12cmd/go/internal/modfetch: skip symlinks in (*coderepo).ZipBryan C. Mills
Tested manually. Before: $ go mod init golang.org/issue/scratch go: creating new go.mod: module golang.org/issue/scratch $ go1.11.2 mod download github.com/rogpeppe/test2@latest go: finding github.com/rogpeppe/test2 v0.0.11 $ find $GOPATH -name goodbye /tmp/tmp.Y8a8UzX3zD/_gopath/pkg/mod/github.com/rogpeppe/test2@v0.0.11/tests/goodbye $ cat $(find $GOPATH -name goodbye) hello After: $ go mod init golang.org/issue/scratch go: creating new go.mod: module golang.org/issue/scratch $ go mod download github.com/rogpeppe/test2@latest go: finding github.com/rogpeppe/test2 v0.0.11 $ find $GOPATH -name goodbye $ find $GOPATH -name hello /tmp/tmp.Zo0jhfLaRs/_gopath/pkg/mod/github.com/rogpeppe/test2@v0.0.11/tests/hello A proper regression test would require one of: • a new entry in the vcs-test server (feasible but tedious, and not easily updated by open-source contributors), or • a way to set up an HTTPS proxy in a script_test, or • a way to explicitly populate the module cache from the contents of a local repository (#28835). Fixes #27093 Updates #28835 Change-Id: I72702a7e791f8815965f0f87c82a30df4d6f0151 Reviewed-on: https://go-review.googlesource.com/c/153819 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
2018-11-29cmd/go/internal/modfetch: make Repo.Zip write to an io.Writer instead of a ↵Bryan C. Mills
temporary file This will be used to eliminate a redundant copy in CL 145178. (It also decouples two design points that were previously coupled: the destination of the zip output and the program logic to write that output.) Updates #26794 Change-Id: I6cfd5a33c162c0016a1b83a278003684560a3772 Reviewed-on: https://go-review.googlesource.com/c/151341 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2018-08-10cmd/go: fix handling of gopkg.in/macaroon-bakery.v2-unstableRuss Cox
When we added v2.0.0+incompatible we generalized the API enough to make it easy to also accepting these gopkg-specific v2-unstable suffixes. Do that. Fixes #23989. Change-Id: Ieabed11a5250c2999d73450c10b20f4c645ad445 Reviewed-on: https://go-review.googlesource.com/128901 Reviewed-by: Bryan C. Mills <bcmills@google.com>
2018-07-19cmd/go/internal/modfetch: move to new pseudo-version designRuss Cox
The original pseudo-version design used versions of the form v0.0.0-yyyymmddhhmmss-abcdef123456 These were intentionally chosen to be valid semantic versions that sort below any explicitly-chosen semantic version (even v0.0.0), so that they could be used before anything was tagged but after that would essentially only be useful in replace statements (because the max operation during MVS would always prefer a tagged version). Then we changed the go command to accept hashes on the command line, so that you can say go get github.com/my/proj@abcdef and it will download and use v0.0.0-yyyymmddhhmmss-abcdef123456. If you were using v1.10.1 before and this commit is just little bit newer than that commit, calling it v0.0.0-xxx is confusing but also harmful: the go command sees the change from v1.10.1 to the v0.0.0 pseudoversion as a downgrade, and it downgrades other modules in the build. In particular if some other module has a requirement of github.com/my/proj v1.9.0 (or later), the pseudo-version appears to be before that, so go get would downgrade that module too. It might even remove it entirely, if every available version needs a post-v0.0.0 version of my/proj. This CL introduces new pseudo-version forms that can be used to slot in after the most recent explicit tag before the commit. If the most recent tagged commit before abcdef is v1.10.1, then now we will use v1.10.2-0.yyyymmddhhmmss-abcdef123456 This has the right properties for downgrades and the like, since it is after v1.10.1 but before almost any possible successor, such as v1.10.2, v1.10.2-1, or v1.10.2-pre. This CL also uses those pseudo-version forms as appropriate when mapping a hash to a pseudo-version. This fixes the downgrade problem. Overall, this CL reflects our growing recognition of pseudo-versions as being like "untagged prereleases". Issue #26150 was about documenting best practices for how to work around this kind of accidental downgrade problem with additional steps. Now there are no additional steps: the problem is avoided by default. Fixes #26150. Change-Id: I402feeccb93e8e937bafcaa26402d88572e9b14c Reviewed-on: https://go-review.googlesource.com/124515 Reviewed-by: Bryan C. Mills <bcmills@google.com>
2018-07-19cmd/go/internal/module: add new +incompatible version build annotationRuss Cox
Repos written before the introduction of semantic import versioning introduced tags like v2.0.0, v3.0.0, and so on, expecting that (1) the import path would remain unchanged, and perhaps also (2) there would be at most one copy of the package in a build. We've always accommodated these by mapping them into the v0/v1 version range, so that if you ran go get k8s.io/client-go@v8.0.0 it would not complain about v8.x.x being a non-v1 version and instead would map that version to a pseudo-version in go.mod: require k8s.io/client-go v0.0.0-20180628043050-7d04d0e2a0a1 The pseudo-version fails to capture two important facts: first, that this really is the v8.0.0 tag, and second, that it should be preferred over any earlier v1 tags. A related problem is that running "go get k8s.io/client-go" with no version will choose the latest v1 tag (v1.5.1), which is obsolete. This CL introduces a new version suffix +incompatible that indicates that the tag should be considered an (incompatible) extension of the v1 version sequence instead of part of its own major version with its own versioned module path. The requirement above can now be written: require k8s.io/client-go v8.0.0+incompatible (The +metadata suffix is a standard part of semantic versioning, and that suffix is ignored when comparing two versions for precedence or equality. As part of canonicalizing versions recorded in go.mod, the go command has always stripped all such suffixes. It still strips nearly all: only +incompatible is preserved now.) In addition to recognizing the +incompatible, the code that maps a commit hash to a version will use that form when appropriate, so that go get k8s.io/client-go@7d04d0 will choose k8s.io/client-go@v8.0.0+incompatible. Also, the code that computes the list of available versions from a given source code repository also maps old tags to +incompatible versions, for any tagged commit in which a go.mod file does not exist. Therefore go list -m -versions k8s.io/client-go@latest will show k8s.io/client-go v1.4.0 v1.5.0 v1.5.1 v2.0.0-alpha.0+incompatible ... v8.0.0+incompatible and similarly go get k8s.io/client-go will now choose v8.0.0+incompatible as the meaning of "latest tagged version". The extraction of +incompatible versions from source code repos depends on a codehost.Repo method ReadFileRevs, to do a bulk read of multiple revisions of a file. That method is only implemented for git in this CL. Future CLs will need to add support for that method to the other repository implementations. Documentation for this change is in CL 124515. Fixes #26238. Change-Id: I5bb1d7a46b5fffde34a3c0e6f8d19d9608188cea Reviewed-on: https://go-review.googlesource.com/124384 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-07-12cmd/go: merge module support from x/vgo repoRuss Cox
This CL corresponds to CL 123361, the final manual CL in that repo, making this the final manual sync. All future commits will happen in this repo (the main Go repo), and we'll update x/vgo automatically with a fixed patch+script. Change-Id: I572243309c1809727604fd704705a23c30e85d1a Reviewed-on: https://go-review.googlesource.com/123576 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2018-06-15cmd/go: add dark copy of golang.org/x/vgoRuss Cox
This CL corresponds to golang.org/cl/118096 (7fbc8df48a7) in the vgo repo. It copies the bulk of the code from vgo back into the main repo, but completely disabled - vgo.Init is a no-op and vgo.Enabled returns false unconditionally. The point of this CL is to make the two trees easier to diff and to make future syncs smaller. Change-Id: Ic34fd5ddd8272a70c5a3b3437b5169e967d0ed03 Reviewed-on: https://go-review.googlesource.com/118095 Reviewed-by: Bryan C. Mills <bcmills@google.com>