aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/go/internal/modcmd/tidy.go
AgeCommit message (Collapse)Author
2021-06-02[release-branch.go1.15] cmd/go: error out of 'go mod tidy' if the go version ↵Bryan C. Mills
is newer than supported This backports the test from CL 319669, but — because of extensive changes to the module loader during the Go 1.16 and 1.17 cycles — the implementation is entirely different. (This implementation is based on the addGoStmt function already present in init.go.) Fixes #46143 Updates #46142 Change-Id: Ib7a0a159e53cbe476be6aa9a050add10cc750dec Reviewed-on: https://go-review.googlesource.com/c/go/+/319710 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-03-10[release-branch.go1.15] cmd/go: don't report missing std import errors for ↵Jay Conrod
tidy and vendor 'go mod tidy' and 'go mod vendor' normally report errors when a package can't be imported, even if the import appears in a file that wouldn't be compiled by the current version of Go. These errors are common for packages introduced in higher versions of Go, like "embed" in 1.16. This change causes 'go mod tidy' and 'go mod vendor' to ignore missing package errors if the import path appears to come from the standard library because it lacks a dot in the first path element. NOTE: This change is not a clean cherry-pick of CL 298749 because parts of modload were substantially rewritten after 1.15. Fixes #44792 Updates #27063 Change-Id: I61d6443e77ab95fd8c0d1514f57ef4c8885a77cc Reviewed-on: https://go-review.googlesource.com/c/go/+/298749 Trust: Jay Conrod <jayconrod@google.com> Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> (cherry picked from commit 56d52e661114be60fb1893b034ac0c5976b622af) Reviewed-on: https://go-review.googlesource.com/c/go/+/298950
2019-11-06cmd/go: make commands other than 'tidy' prune go.mod less agressivelyBryan C. Mills
Updates #31870 Updates #33326 Fixes #34822 Change-Id: I1337f171133c20800eacc6b0955ede5a394ea7eb Reviewed-on: https://go-review.googlesource.com/c/go/+/204878 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-22cmd/go: support -modcacherw in 'go mod' subcommandsJay Conrod
The -modcacherw flag is now registered in work.AddModCommonFlags, which is called from work.AddBuildFlags, where it was registered before. 'go mod' subcommands register the flag by calling work.AddModCommonFlags directly. Also, build commands now exit with an error if -modcacherw is set explicitly (not in GOFLAGS) in GOPATH mode. Updates #31481 Change-Id: I461e59a51ed31b006fff4d5c57c2a866be0bbf38 Reviewed-on: https://go-review.googlesource.com/c/go/+/202563 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-05-16cmd/go: always add 'go' directive to the go.mod file if missingBryan C. Mills
Updates #30790 Fixes #31960 Change-Id: Ib3ac074cf1f98fe69f53af82d2a0441582116570 Reviewed-on: https://go-review.googlesource.com/c/go/+/176925 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-04-19cmd/go: only add a 'go' directive on 'go mod tidy' or when a conversion occursBryan C. Mills
If the go.mod file exists and is empty, we initialize it from any of various formats supported by legacy dependency-management tools. We also initialize the 'go' directive at that point: we know that the go.mod file is incomplete, because it does not reflect the information in the legacy configuration file, and since we know that the go.mod file is incomplete, we should complete it with as much information as we have — including the version of the language currently in use. However, if there is no legacy configuration file present, then we cannot infer that the go.mod file is incomplete: it may correctly specify a module without external dependencies. In that case, we should not initialize the 'go' directive either: the user will not be expecting unnecessary edits to the go.mod file, and we generally do not make unnecessary-but-helpful edits unless 'go mod tidy' is invoked explicitly. Fixes #30790 Fixes #31100 Change-Id: I05a7872bce54a917c10d910cd9a616cab52e2730 Reviewed-on: https://go-review.googlesource.com/c/go/+/169877 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-02-11cmd/go/internal/modcmd: use replaced paths to break cycles in 'go mod tidy'Bryan C. Mills
Fixes #30166 Change-Id: I4704b57ed48197f512cd1b818e1f7d2fffc0d9ce Reviewed-on: https://go-review.googlesource.com/c/161898 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-12-12cmd/go: retain sums for replacement modules in 'go mod tidy'Bryan C. Mills
Fixes #27868 Change-Id: I6c2d221c4325a2f44625e797a82735d812ee0ec1 Reviewed-on: https://go-review.googlesource.com/c/153817 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2018-08-18cmd/go: fix go mod tidy crash on empty moduleRuss Cox
Fixes #27066. Change-Id: Iede4385ad86b42d7d90814965b161a7e64d29833 Reviewed-on: https://go-review.googlesource.com/129799 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-08-01cmd/go: split go mod into multiple subcommandsRuss Cox
The current "go mod" command does too many things. The design is unclear. It looks like "everything you might want to do with modules" which causes people to think all module operations go through "go mod", which is the opposite of the seamless integration we're going for. In particular too many people think "go mod -require" and "go get" are the same. It does make sense to put the module-specific functionality under "go mod", but not as flags. Instead, split "go mod" into multiple subcommands: go mod edit # old go mod -require ... go mod fix # old go mod -fix go mod graph # old go mod -graph go mod init # old go mod -init go mod tidy # old go mod -sync go mod vendor # old go mod -vendor go mod verify # old go mod -verify Splitting out the individual commands makes both the docs and the implementations dramatically easier to read. It simplifies the command lines (go mod -init -module m is now 'go mod init m') and allows command-specific flags. We've avoided subcommands in the go command to date, and we should continue to avoid adding them unless it really makes the experience significantly better. In this case, it does. Creating subcommands required some changes in the core command-parsing and help logic to generalize from one level to multiple levels. As part of having "go mod init" be a separate command, this CL changes the failure behavior during module initialization to be delayed until modules are actually needed. Initialization can still happen early, but the base.Fatalf is delayed until something needs to use modules. This fixes a bunch of commands like 'go env' that were unhelpfully failing with GO111MODULE=on when not in a module directory. Fixes #26432. Fixes #26581. Fixes #26596. Fixes #26639. Change-Id: I868db0babe8c288e8af684b29d4a5ae4825d6407 Reviewed-on: https://go-review.googlesource.com/126655 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>